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FOREWORD 


This is the Phase 1 Final Report of the Scheduling Language 
and Algorithm Development Study performed by Martin Marietta 
Corporation, Denver Division, under Contract NAS9-13616. The pur- 
pose of this study was to conceive and specify a high-level com- 
puter programming language and a program library to be used in 
writing programs for scheduling complex systems such as the Space 
Transportation System. This report is presented in three volumes 
plus an appendix: 

Volume I - Study Summary and Overview 

Volume II - Use of the Basic Language and Module Library 
Volume III - Detailed Functional Specification for the Basic 
Language and the Module Library 
Appendix — Study Approach and Activity Summary 

Volume I summarizes the objectives and requirements of the 
study and discusses the ’‘why" behind the objectives and require- 
ments. Unique results achieved during the study or unique fea- 
tures of the specified language and program library are then de- 
scribed and related to the "why" of the objectives and require- 
ments. Finally, a description of the significance of study re- 
sults, in terms of expected benefits, is provided. 

Volume II summarizes the capabilities of the specified sched- 
uling language and the program module library. It is written with 
the potential user in mind and, therefore, provides maximum in- 
sight on how the capabilities will be helpful in writing scheduling 
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programs. Simple examples and illustrations are provided in ^ 

Volume II to assist the potential user in applying the capabilities 
of his problem. 

The detailed functional specifications presented in Volume III 
are the formal product of Phase 1. These specifications are written 
as requirement s for software implementation of the language and the 
program modules, and are aimed at a specific audience. 

A separate Appendix summarizes the analyses, describes the 
approach used to identify and specify the capabilities required 
in the basic language, and presents results of the algorithm and 
problem modeling analyses used to define specifications for the 
scheduling module library. The appendix is directed toward the 
reader who is interested in how the study conclusions and results 
were reached. 
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1.0 Introduction 



1.0 


INTRODUCTION 


Volume II presents both PLANS (Programming Language. for Allo- 
cation and Network Scheduling) and the programming library modules 
from the user’s viewpoint. It describes capabilities and gives 
many specific examples to provide insight to the potential use- 
fulness of the language for building scheduling and resource allo- 
cation software. 

This volume is intended to provide a basic understanding of 
the nature and use of PLANS. It is not a detailed user guide such 
as might be used by a programmer for actual coding. While this 
document is meant to serve that function on an interim basis, a 
detailed user guide will be produced as a part of the PLANS imple- 
mentation (Phase II) effort. The discussion in this volume is not 
meant to serve as a functional specification of PLANS. The de- 
tailed functional specifications form a part of Volume III of this 
report. 

Section 2.0 of this volume describes the characteristics of 
the PLANS language itself. Section 3.0 discusses the character- 
istics of scheduling problems and how they can be tpodeled. The 
framework described is referred to here as a generic scheduling 
operations model. The application of various library modules in- 
cluding solution algorithms is discussed in the context of this 
model. Illustrative examples are included in Section 4.0 where 
both modeling and coding are presented. 
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USE OF THE PLANS LANGUAGE 


PLANS (Programming Language for Allocation and Network Sched- 
uling) is a computer programming language designed for use in the 
expression of procedures for solving schedule construction and 
resource allocation problems. It is a high-level language in- 
tended to allow easy, direct expression of the kinds of functions 
frequently found in scheduling programs and algorithms. The close 
correspondence between basic functional operations and PLANS 
statements is intended to allow the scheduling program designer 
to easily accomplish for himself both initial programming and 
program modification. A detailed" discussion of these considera- 
tions, together with the analytical results which caused PLANS to 
take its current form, can be found in the appendix to this report. 
BASIC LANGUAGE STRUCTURE AND STATEMENTS 

For reasons outlined in the appendix, the basic program struc- 
ture and syntax of PLANS are similar to those of PL/I. A brief de- 
scription of their basic characteristics is given below. For a 
more detailed introduction, see A GwidjB to PL/ 1 foT FORTRAN UseTS^ 
IBM Document SC20-1637-3. For detailed general information, see 
IBM System/ 360 Opevating System PL/ I (F) Language Reference 
Manual, IBM Document GC28-8201-4, and the corresponding Programmer* 
Guide, GC28-6594, or other similar manuals. 


The basic structure of PLANS is a hierarchic block structure. 
Groups of statements may be combined into logical blocks called 

PROCEDURE blocks, BEGIN blocks, and DO-groups. These blocks are 
preceded by PROCEDURE, BEGIN, or DO statements and followed by 
END. These blocks may then be nested at will, yielding a hier- 
archic structure such as that shown in Fig. 2.1-1. 

Note in Fig. 2.1-1 that statements are terminated by semi- 
colons and that statement labels are indicated by colons. PLANS, 
like PL/I, is a free-format language with no card column re- 
strictions for specific types of information. A statement may be 
several cards long or, conversely, several statements may appear 
on a card. Indentation has no significance to PLANS and can be 
used as desired to improve program structure visibility. 

A: PROCEDURE; 

statement - al 
statement - a2 
B: BEGIN; 

statement - bl 
statement - b2 
C: PROCEDURE; 

statement - cl 
statement - c2 

D: DO; 

statement - dl 
statement - d2 

E: BEGIN; 

statement - el 
statement - e2 
END; . 

statement d3 

END; 

statement - c3 

END; 

statement - b3 

END; 

statement - a3 

END; 

Fig. 2.2-2 

PLANS (and PL/I) Uierarohio Block 
Program Structure 


4 



Procedure blocks correspond to main programs or subroutines. 

If a procedure appears within another procedure (as PROCEDURE C 
is within PROCEDURE A, for instance), it is executable only by 
means of a CALL statement. Thus, if statement-b2 is not a CALL 
or other transfer— of —control statement, it will be followed 
logically by statement-b3, with transfer of control skipping a- 
round PROCEDURE C. BEGIN blocks and DO-groups, on the other hand, 
are executed in line and are for many practical purposes equiv- 
alent to single statements. 

Aside from the fact that block-structured languages ' simplify 

program structure and may improve program readability considerably, 

they also tend to increase the power, of the language by providing 

a natural mechanism for treating a whole block of statements as 

a logical entity. Thus, by way of simple example, the statements 

SUM = 0; 

IF K < 10 

THEN DO J = 1 TX) K; 

SUM = sun J; 

END; 

sum the first K integers if, and only if, K < 10. Otherwise 
SUM = 0. 

It is a basic property of block-structured languages that 
variables have global (rather than local) scope unless specified 
otherwise. Thus, where a FORTRAN subroutine is written as a 
separate entity from the calling program and uses variables whose 
names are meaningful only within the subroutine (i.e,, names that 
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are local), the procedures (subroutines) of a hierarchic language 
are usually nested within the calling program, and have access to 
all its variables unless explicitly excluded. 

\'7hen using a procedure as a subroutine, it is usually desirable 
to pass a parameter list as part of the procedure call and return. 
This can be explicitly accomplished in very much the same way as 
in most languages, using statements of the form 

CALL EVAL_W(X1. Yl, Zl, W) ; 

and 

EVAL_W: PROCEDURE(X, Y, Z, U); 

where the names used for the parameters are free to vary between 
the two statements. Incidentally, note use of the underline 
( _ ) symbol , This , combined with a maximum name length of 31 
characters for most purposes, allows one to use meaningful and 
readable labels, variable names, etc (e.g., THIS_IS_A_READABLE_NAME ) . 

This has been a rather cursory treatment of the PLANS (PL/ I) 
program structure. While this structure is easy to use success- 
fully, its more sophisticated ramifications clearly exceed the 
scope of this volume. The reader is again referred to the PL/I 
documents mentioned at the beginning of this section for further 
details. 

PLANS incorporates a fairly complete set of ordinary arith- 
metic, transf er-of-control , and conditional and iterative state- 
ments that are treated in essentially the same way they are used 
in PL/I. Illustrative examples of these statements follow with 
brief descriptions but without rigorous definition. 
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PLANS uses conventional arithmetic assignment statements such 
as 

XVAR = (Y*3.0)-((Z'**2)/26)*Y; 

Conventional operator priorities and lef t-to-right performance 
rules apply for the most part, so that the statement 

XVAR = Y * 3.0 - Z**2/26*Yi 

has the same meaning as the statement above. 

Aside from the CALL statement, which has already been dis- 
cussed, the only transfer-of-control capability required for most 
purposes is the simple GO TO statement. This statement has the 
form 

GO TO A__STATEMENT_LABEL; 

where A_STATEMENT_LABEL is a statement label, as 

A_STATEMENT_LABEL: XVAR = Y*3.0-Z**2/26*Y ; . 

Conditional statements are similar to those of PL/I and 

therefore are a good deal more powerful than those familiar to 

FORTRAN programmers. The IF .. .THEN ... ELSE .. . syntax is used 

( IF. . . THEN . - . is legal), and IF statements can be nested. No 

parentheses are required around the conditional expression (after 

"IF"). Thus, the following program segment is legal and behaves 

in a way that should be familiar. 

IF YIELD SIGN = 1 

THEN IF TRAFFIC JCOMING = 1 
THEN GO TO STOP; 

ELSE GO TO GO; 

ELSE IF ST0P_SIGN = 1 
THEN GO TO STOP; 

ELSE GO TO GO; . 

In addition to the noniterative DO-group shown in Fig. 2.1-1 and 
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the two special iteration statements that are peculiar to PLANS, 
PLANS also uses two common forms of iterative DO statements. 

The first of these is the usual delimited form 

DO I = 1 TO 10; 

or 

DO I = 2 TO 20 BY 2; 
or 

DO I = (K-l)**2-14 TO A*B*C; 

while the second is an open-ended form 

DO WHILE (A*X**2<27); . 

In each of these forms, the condition is tested at the beginning 

* 

of the DO-group, rather than at the end, so that a DO-group 

starting 

DO I = 1 TO 0; 

or 

« 

A = 20; 

DO WHILE (A < 10); 

would not be executed at all. Of course, the use of END to ter- 
minate the DO-group obviates the need to refer to a statement 
label in the DO statement. 

2 . 2 LABELED TREES 

The principal difference between PLANS and most other pro- 
gramming languages is that PLANS is oriented primarily toward the 
manipulation of ordered, labeled tree structures. In preparation 
for a discussion of the PLANS tree operations, this section will 
define a labeled tree and establish both graphical and textual 
conventions for representing such trees. 
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Figure 2.2-1 illustrates a labeled tree, as well as our 
graphical format for trees. The tree is, of course, a hierarchical 
data structure. The branching points are called yiod.es ^ and the 
root Ylod& is shown at the top. The nodes are represented graphic- 
ally by circles. The name of the tree, in this case $PAYL0AD, is 
shown above the root node. The dollar sign is a special character 
used to identify tree names so the PLANS compiler can discriminate 
them from variable names. Each node has a Zahet (the character 
string to the right of the node), but the label may be niiVl , In 
the figure, the only node shown with a null label is the root 
node, but any node can conceivably have a null label. 

The nodes exactly one level below a given node are called its 
descendants. The root node of the tree in Fig. 2.2-1 has four 
descendants. The node labeled LIFESCIENCE has two descendants, 
which, in turn, are labeled WEIGHT and WINDOW. Nodes that have 
descendants are called nonterminal nodes; nodes without descen- 
dants are called terminal nodes. There are 11 terminal and 9 non- 
terminal nodes in the figure. In addition to a label, a terminal 
node has a value, which may be either a character string or a 
numeric value. Values are shown t^felow their terminal nodes. Like 
labels, values may be null- 

While the graphical format is convenient for displaying con- 
ceptual tree structures and for demonstrating the effect of 
specific PLANS statements, it is too cumbersome and rigid for 
convenient use in the display of specific tree structures, espe- 
cially large ones. For this purpose, the textual format is used. 
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The tree of Fig. 2.2-1 is expressed in the form shown in Fig. 
2.2-2. In this case, the structure is defined by the indentation 
pattern, rather than by node-connecting lines. Each line of text 
represents a node. The information occurring first on a line is 
the node label, while the values of terminal nodes are separated 
from the corresponding labels by a hyphen (-) character that is 
surrounded by blanks. In order to allow rigorous definition of 
tree structures in which some nodes have null labels, it is nec- 
essary to employ a special convention for representing them. Null 


$PAYL0AD 

LIFESCIENCE 

WEIGHT - 9000 
WINDOW 

START - 10 
END - 143 
TELESCOPE 
WINDOW 

START - 40 
END - 216 
MANUFACTURING 
WINDOW 

START - 8 
END - 840 
GEOPHYSICAL 
LENGTH - 18 
WEIGHT - 8000 
WINDOW 

START - 241 
END - 318 

Fig. 2.2-2 The Tree of Fig. 2.2-1 in Textual Format 
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labels are represented by a cent sign (d) • This convention is 
occasionally employed in the graphical format, although it is 
unnecessary there. 

It can be seen in Fig. 2.2-2, that while numeric values are 
given for terminal payload descriptor nodes, physical units are 
not; i.e. 9000 is given for the weight and 10 for the window start 
time of the lifescience payload, but no indication is given whether 
these are pounds, kilograms, seconds, etc. The option exists to 
specify these physical units in the application program logic, 
in which case the information in the example is adequate. The 
alternative is to enter physical unit values as character string 
input data in the tree structure textual format. For readability, 
a shorthand format has been adopted to present the value of phy- 
sical units, thus 

$PAYL0AD 

LIFESCIENCE 

WEIGHT - 9000 
- LBS 

WINDOW 

START - 10 
- HRS 
END - 143 
- HRS . 


This is a shorthand form in the sense that the numeric and char- 
acter string data are properly different values for two different 
null labeled nodes, that is 

$PAYL0AD 

LIFESCIENCE 

WEIGHT 

i - 9000 
(t - LBS . 
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Entry of multiple values for a labeled node, as in this example, , 

would require the inclusion of logic within the application pro- 
gram, to recognize the character string node values and associate 
them correctly with the numeric node values. 

An additional convention, which has been adopted, is the use 
of parenthesized labels and values to represent variable data in 
the definition of a particular tree application. If a label or 
value occurs without parentheses, it is assumed that the character 
string shown is literally present in the tree. For example, the 
tree 

$PAYL0AD 

LIFESCIENCE 

WEIGHT - 9000 
LENGTH - 27- 

contains only actual values and labels. But if one wanted to 

show only the nature of the information contained in this tree, 

the following form might be used. 

$PAYL0AD . 

(PAYLOAD NAME) 

(CHARACTERISTIC) - (VALUE) 

(CHARACTERISTIC) - (VALUE) 

(PAYLOAD NAME) 


2.3 PLANS TREE ACCESS IffiCHANISMS 

PLANS provides the programmer with a number of simple and 
powerful means of accessing and updating the information con- 
tained in the labeled tree structures discussed in the previous 
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section. These methods are based on the notion that the programmer 
can "point" to a particular tree node by specifying which tree it 
is in, which descendant of the root node it is under, which de- 
scendant of that node it is under, etc. (Remember that the term 
"descendant," as used here, means irmediate descendant.) 

Suppose, for example that information about the telescope pay- 
load in Fig. 2.2-1 is desired. Because the name of the tree is 
$PAYL0AD and the name of the payload in question is tELESCOPE, 
the programmer might write $PAYL0AD. TELESCOPE to access this in- 
formation. This is an example of qualification by label. 

Alternatively, qualification can be done by position, using 
the familiar subscript notation. As was mentioned before, but not 
explained in detail, PLANS trees are ordered trees; that is, the 
ordering of the descendants of a node is significant. Unless 
action is taken to change or reorder a tree structure, the order 
remains constant. In the present example, since TELESCOPE is the 
second payload, information about that payload can be referred to 
as $PAYL0AD(2), as well as $PAYL0AD. TELESCOPE. Examples of simple 
qualification by label and by subscript are shown in Fig. 2.3-1. 

Figure 2.3-1 also illustrates the use of one of two keywords, 
LAST and NEXT, which have special meaning when used as subscripts 
in PLANS tree access and update statements. LAST allows the pro- 
grammer to refer to the last information appended below a given 
node without knowing either the label or the index of the node he 
wants. Thus, for example $PAYLOAD(LAST) refers to the geophysical 
payload in the figure. Similarly, NEXT refers to the next subnode 
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1-2 •‘S 



$PAYLOAD. TELESCOPE 
(OR.$PAYLOAD (2) ) 


$PAYLOAD (LAST) 

(OR $PAYLOAD. GEOPHYSICAL 
OR $P AY LOAD (4)) 


Fig. 2.3-1 Basic Tree Access Mechanisms 


afteT the last one appended below a given node. The reference 
is therefore to a node that does not yet exist. NEXT is mean- 
ingful only in the context of updates, but is mentioned here be- 
cause of its association with LAST. 

Access qualified by label or by subscript can be continued 

to any desired depth in the tree, and labels and subscripts can 

be mixed at will. Consider for example, the node with value 216 

in Fig. 2.3-1, Several ways of ’’pointing" to the node are: 

$PAYL0AD. TELESCOPE. WINDOW. END 
SPAYLOAD . TELESCOPE . WI ND0W( 2 ) 

$PAYL0AD.TELESC0PE(1 ) .END 
$PAYL0AD(2).WIND0W(2) 

$PAYL0AD . TELESCOP E ( LAST )( LAST ) 

$PAYL0AD{2)(1)(2) . 

References to particular nodes may be intended to refer to a 

tree substructure (l.e., the node "pointed" to, including its 

label, and anything below that node in the tree) or to a value. 

The meaning of a tree reference depends on the context in which 

the reference occurs. Thus, a statement which commands that a 

node be "pruned" (i.e., deleted from its tree) is obviously a 

structure reference, while a statement like 

WIND0W_DURATI0N=$PAYL0AD(2). WINDOW. END 
-$PAYL0AD(2) .WINDOW. START; 

refers, because of its arithmetic nature, to the values (216 and 
40) of the two tree nodes used in the statement. 

Tree relational expressions are a source of considerable 
power in PLANS. These are logical (Boolean) expressions that have 
a value of TRUE or FALSE. These expressions are analogous to 
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arithmetic relational expressions (e.g., XVAR < WAR) and are 
usable in IF ... THEN ... ELSE statements. 

PLANS tree relations include IDENTICAL TO, SUBSET OF, 
and SUPERSET OF. The expression $TREE__A IDENTICAL TO $TREE_B 
has the value TRUE if, and only if, the entire substructure of 
$TREE_A (or the value of $TREE_A , if it has no descendants) is 
identical to that of $TREE_B with respect to structure and order, 
labels, and values. The expression $TREE_A SUBSET OF $TREE_B 
has the value TRUE if, and only if, for each first-order sub- 
structure of $TREE __A , there exists an identical first-order 
substructure in $TREE_B . The expression $TREE_A SUPERSET OF 
$TREE B is equivalent to $TREE_B SUBSET OF $TREE_A . 

In each of the sample expressions above, any node reference 
can be substituted for $TREE_A and $TREE_B, and these Boolean 
expressions can be combined with Boolean AND (&) and OR (j) 
operators in the usual fashion. Thus, one can write a statement 
like 

IF $PAYLOAD(I)SUBSET OF $CANDIDATES 
& $PAYL0AD(I). WINDOW. END > LAUNCH__DATE 
THEN GO TO THIS_PAYL0AD_0K; 

Note that this statement contains node references that are 
structural and a node reference that is arithmetical. 

Tree relational expressions are most useful in conjunction 
with two keywords, FIRST and ALL , which have special meaning 
when used as label qualifiers in PLANS tree node references. 
$PAYL0AD. FIRST, when used by itself, is a legal expression with 
the same meaning as $PAYL0AD(1). The important usage of FIRST 
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Is in an expression like $PAYL0AD. FIRST : (CONDITION ) . This ex- 
pression means "find the first descendant of the node $PAYL0AD 
that satisfies the condition in parentheses," where the condition 
is a Boolean expression* An example is shown in Fig. 2.3-2. The 
operation desired by the programmer might be stated, "find the 
first descendant of $PAYL0AD whose launch window duration is 
greater than 150 days." Expressed in more procedural terms, the 
operation might be, "Consider each element (i.e., each descendant 
of $PAYL0AD) in turn. Calculate the launch window duration of 
the element being considered. If greater than 150, proceed as if 
it had been referenced by name." Note the correspondence of the 
use of the word ELEMENT in this procedural description and in the. 
corresponding tree node reference, $PAYL0AD. FIRST :(ELEf€NT. WINDOW. 
END - ELEMENT. WINDOW. START >150) . 

The label qualifier ALL works in a similar manner, but rep- 
resents a reference to more than one descendant. Thus, if 
$PAYL0AD refers to the tree structure of Fig. 2.3-1, then 
$PAYL0AD.ALL refers to the portion of that structure indicated 
in Fig. 2.3—3. Writing $PAYL0AD.ALL is equivalent to "pointing" 
to $PAYL0AD(1), $PAYL0AD $PAYL0AD(LAST) , each in turn. 

$TREE.ALL is therefore a way of referring to the siibstvuatuTe 
of a node without including the node itself. 

It should be noted that the position of a label or sub- 
script qualifier in a PLANS tree node reference always corres- 
ponds to the level of the node in the structure itself. (A so- 
phisticated reader who has looked at a PLANS program that uses 
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Fig, 2,3'-2 Conditional Access Using Qualifier '\FIRST^* 
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subroutines may detect an apparent exception to this statement. 
Please be assured that it is not an exception, but merely a ques- 
tion of tree name scope.) While this correspondence of position 
is clear in a tree node reference like $PAYL0AD(2) .WINDOW. END, it 
will be helpful to the user to keep in mind that it also applies 
to the use of FIRST and ALL. Thus $PAYLOAD.ALL is a reference 
to one or more nodes that are one level hetow $PAYL0AD . 

As in the case of FIRST, ALL is most usefully employed in 
expressions like $PAYL0A0. ALL : {condi ti on) , where the condition is 
a Boolean expression. In this case, instead of a single node, the 
reference is to all the subnodes of a particular node that satisfy 
the stated condition. An example is shown in Fig. 2.3-4. This 
"all such that" capability is very powerful as a means of filter- 
ing sets of elements for a particular set of characteristics. 

Sometimes the programmer needs to refer to the label on a 
node rather than to its value or the structure it represents. 

For this purpose, PLANS provides the special function LABEL. 

For example, the reference LABEL ($PAYL0AD{ 3) ) applied to the 
tree of Fig. 2.3-1 yields the character string MANUFACTURING. 

A second special function of PLANS is NUMBER. This function 
returns the number of descendants possessed by a given node. 

Thus, the expression NUMBER($PAYLOAD) applied to the tree of 
Fig. 2.3-1 yields the numerical value 4. 

A particularly important tree access feature is Indirect 
referencing. Unless the programmer resorts to very expensive 
iterative tree searching there is no way, without indirect 
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Fig. 2.Z-4 Conditional Aaoess Using Qualifier ".ALL" 



referencing, that he can write a program to schedule shuttle 
flights that do not contain words like PAYLOAD, ORB ITER, etc. In 
order to access information about these resources, he wants to 
use them as labels for qualified access or, conceivably, as tree 
names. What is needed is a capability that allows the character- 
istics of a problem to reside in the data, rather than the pro- 
gram. Only in this way can a program that schedules shuttle flights 
also, schedule machine shop operations. What the programmer needs 
is the capability to read in, as data, the labels he will use to 
access particular tree nodes. Accordingly, PLANS allows the kind 
of indirect referencing illustrated in Fig. 2.3-5. What the pro- 
grammer is attempting to do in this illustration is to access in- 
formation about the resource types named in a tree called 
$RESOURCE_REQUIREMENTS . He therefore writes the tree node expres- 
Sion $RES0URCE_INF0.#{.$RES0URCE_REQUIREMENTS(1)) to access inf or- 
mation about the first such resource type. This expression might 
be read, ’’the descendant of the node $RES0URCE_INF0 whose label is 
the character string found as the current value of the node 
$RESOURCE_REQUIREMENTS( 1)”. The programmer is in effect saying, 
’’Behave as if I had written $RES0URCE__INF0 .ORBITER, but allow me 
the freedom to use some other label than ORB I TER by changing the 
dcLta^ wi-thout changing the pipog-pcm. 


23 



$RESOURCEJNFO $RESOURCE_REQUIREMENTS 



Fig. 2.Z-S Indirect Referencing 

2.4 PLANS TREE UPDATE MECHANISMS 

The basic PLANS tree update mechanism is the tree assignment 
statement. The reader is undoubtedly familiar with the properties 
of such ordinary arithmetic assignment statements as 
XVAR - WAR; . 

The function of such a statement might be described algorithmically 
as: (1) destroy the current "contents" of the variable XVAR, (2) 

make an exact copy of the current "contents" of the variable WAR 
without modifying WAR, and (3) place the copy "in" XVAR. l^ile 
the execution of such a statement is more direct than this 
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algorithm would indicate, the analogy with tree assignment state- 
ments should be clear if the reader will think in terms of this 
algorithm while considering the statement 
$XTREE = $YTREE; . 

This statement (1) destroys the current value or substructure 
of $XTREE, (2) creates a copy of the node and value or substruc- 
ture of $YTREE, and (3) places the resulting structure at $XTREE, 
The net result, as with the arithmetic assignment statement, is 
one of replacement or assignment of a new value. 

Of course, the tree node expressions in a tree assignment 
statement may be more complex than simple tree names. Several 
examples are shown in Fig. 2,4— 1, and should be considered in de- 
tail, Figure 2.4—1 (a) shows the initial condition of two trees, 
$X and $Y , which will be successively modified by the execution 
of a series of tree assignment statements. The first such state- 
ment, $X(3) = $Y.C, modifies the tree $X, as shown in (b) . Note 
that the original third subnode of $X has been deleted and re- 
placed with a copy of the node $Y.C, and that the tree $Y has not 
been altered at all. 

Beginning with the trees in (b) , the statement $X.D = $Y(LAST) 
results in the modified $X shown in (c) . If $X had had a node 
labeled **D" , it would have been replaced as in the previous ex- 
ample. Because the left-hand side of the tree assignment state- 
ment referred to a node not yet in existence, a new snbnode of |)( 
was created. The new subnode is always added at the right. Thus, 
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(c) Trees after $X.D = $Y(LAST) 


$X $Y 



(d) Trees after $X(2) - $Y.E 

Fig. 2. 4^1 Resutts of cl SeguenoB of Tvee AssignynBnt StcitBLnents 
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in the absence of a node $X.D, the statement $X.D = $Y(LAST) 
behaves like the statement $X(NEXT) = $Y(LAST). 

What if the right-hand side represents a nonexistent node? 
This case is illustrated in (d) . In (c) , there is no node $Y,E. 
Therefore, the statement $X(2) = $Y.E (1) deletes the contents 
of $X(2), (2) makes a copy (null) of $Y.E, and (3) replaces $X(2) 
with the copy. That is, $X(2) is replaced by a null node under 
these circumstances. This convention is consistent with the ex- 
ecution of the statement when the node in question exists, and 
has the advantage that it allows the programmer to test expli- 
citly for a null node ("IF $X(2) = $NULL THEN...") if he is in 
doubt about the existence of the node referred to on the right- 
hand side of the tree assignment statement. This same behavior 
occurs when, a conditional tree access is used in which the con- 
dition is not satisfied. Suppose, for example, that the program- 
mer had wanted to replace $X(2) in the example by a copy of the 
first descendant of $Y that had a substructure. He might. have 
written $X(2) = $Y. FIRST: (NUMBER(ELEMENT) > 0). Because none of 
the descendants of $Y satisfies the condition, the result would 
have been identical to that resulting from $X(2) = $Y.E . Both 
statements yield the same result as $X(2) = $NULL . 

Section 2.3 gave several illustrations of automatic con- 
version in which PLANS tree node references occurring in an 
arithmetic context were implicitly evaluated (i.e., the value of 
the referenced node was used, rather than the node itself, which 
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is a structure). Analogously, character strings and arithmetic 
expressions may appear in tree assignment statements, as illus- 
trated in Fig. 2.4-2. 

Figure 2. 4-2 (a) shows the initial condition of the tree $X. 

Figure 2.4-2(b) shows $X as modified after the execution of the 
statement $X.B = ‘ABC. Described algorithmically, here is what 
has happened: (1) the value or substructure of $X.B has been 

deleted, because $X.B occurs on the left-hand side of a tree 
assignment statement; (2) the right-hand side of the statement has 
been evaluated as a tr*ee expression, because that is what is 
called for by the tree assignment statement, and (3) a copy of the 
tree structure referred to on the right-hand side has replaced the 
value or substructure of $X.B. By this description, then, this 
tree assignment statement operated like any other. But how is 
something, evaluated as a tree expression when it is in fact a 
character string? 

Any time a character string or arithmetic expression occurs, 
when the context clearly calls for a tree expression, a dummy tree 
is created. This dummy tree has only a single node, the root 
node, which has a null label. The value of the node is the string 
or arithmetic value specified in the PLANS expression, in this 
case the string 'ABC". The dummy tree is then used just as if the 
programmer had explicitly created the tree and placed the tree's 
name in the program. In the case of the example, the result is 
the same as if the programmer had written $X.B = $ DUMMY , where 
$DUMMY is a tree with one node, no label, and the string value 'ABC. 


28 



$x 



2 4 6 


(a) Original Tree 
$X 



2 ABC 6 

(b) Tree after $X.B = 'ABC 


$X 



2 13.5 6 

(d) Tree of (a) after $X.B = $X.C + 7.5 

Fig* 2,4-2 Type Conversion in Tree Assignment Statements 



As suggested in the explanation above, the same mechanism 
applies when an arithmetic expression appears in a context that 
requires a tree node reference. Thus, application of the state- 
ment $X.B = 2*4 to the tree of 2. 4-2 (a) yields the result shown 
in (c). The value of the arithmetic expression, in this case 8, 
is calculated, placed on a dummy node, and becomes the value of 
$X.B. It may occur to the reader that the same behavior could 
as well be described as replacement of the value (or substruc- 
ture) on the left by the value of the expression on the right. 

As the discussion of Fig. 2.4-4 will show, this is not always 
true. It will be helpful, therefore, to think in terras of the 
generation of a dummy node when considering statements of this 
type. 

Figure 2.4-2(d) shows a statement of the same basic sort as 
that of (c). In this case, the arithmetic expression on the 
right-hand side involves a tree node reference. Because $X.C 
occurs within an arithmetic expression, it has the value 6, just 
as if $X.C were an arithmetic variable name. Therefore, the 
statement $X.B = SX.C + 7.5 results in substitution of the nu- 
meric value 13.5 at $X.B. 

The previous discussion has shown a mechanism whereby the 
value or substructure of a node can be replaced. Sometimes it 
is the node tahet that requires modification. In this case, the 
label assignment statement is used. LABEL is a special PLANS 
function that takes as its argument a tree node reference. 
LABEL($X(1)) is a reference not to the node $X{l) and its 
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substructure, but to its label alone. The LABEL function can 
appear anywhere a character string can appear in a PLANS program. 

In addition, it can appear on the left-hand side of an equal sign, 
as Fig. 2.4-3 shows. Such a statement is a command to replace the 
current label of the specified node with the new string, which is 
obtained by evaluating the expression to the right of the equal 
sign. 

Consider Fig. 2,4-3; (a) shows the initial state of the tree 
$X. Figure 2'. 4-3 (b) illustrates the effect of the label assign- 
ment statement LABEL($X(l)) - 'D'; , which simply replaces the cur- 
rent label of the node $X(l), "A", with a new string, "D”. The 
label assignment statement only replaces labels, having no struc- 
tural effect if the referenced node already exists. If the indi- 
cated node does not exist, it is established, with a null value 
and the indicated label. 

The statement illustrated in (c) has exactly the same effect 
as that of (b). It makes no difference whether the node .is ref- 
erenced by label ($X.A) or by subscript ($X(l)). The effect of 
the statement is the same. As the discussion of Fig. 2.4-4 will 
show, this is not true of all tree statements. 

Figure 2.4-3 (d) is another illustration of automatic conver- 
sion. The right-hand side of the statement LABEL($X(l)) = $X.C 
is a tree expression, but the context calls for a string or numer- 
ical value. The value of $X.C is therefore obtained, and replaces 
the label of $X(1). An additional concept is illustrated here: 
labels can be numerical values. In fact, anything that can be a 
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(a) Original Tree 


$X 



(b) Tree after LABEL ($X(1)) = 'O’ 


$X 



(c) Tree of (a) after LABEL($X.A) - ‘O' 


SX 



(d) Tree of (a) after LABEL($X(l)) = $X.C 
Fig, 2,4-3 Label Assignment Statements 
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value can be a label, and vice versa. However, nodes that have 
numerical values (or strings not having identifier syntax) cannot 
be accessed by label in a PLANS' program. Thus, $X.6 is not a 
legal expression. On the other hand, $X(l) is still a legitimate 
way to refer to this node. This property can be used to advant- 
age in some numerical applications. 

Figure 2.4-4 illustrates an important property of PLANS tree 
operations, the treatment of the label on the base node of the 
operation. The "base node" is the node at which a modification 
occurs. In the case of a tree assignment statement, the node 
named on the left-hand side is the base node. The question is. 
When does the existing label on the base node remain, and when 
is it replaced? It is unlikely that any decision rule that might 
be incorporated into PLANS would successfully anticipate the de- 
sires of the programmer in all cases. Therefore, a simple de- 
cision rule has been incorporated that should be right most of 
the time. If the base node was accessed by label, the label re- 
mains; if by subscript, the label is replaced. 

In Fig. 2.4-4(b), for example, the statement $X.B - $X.C has 
been executed on the tree of (a). The base node, $X.B, retains 
its original label, "B", because the programmer specified the 
node by that label. Thus, while the value or substructure of 
$X.C will appear on the node $X.B after execution of this state- 
ment, the base node label will be left unchanged. In (c) , on the 
other hand, the base node label is replaced. In this case, the 
statement $X(2) = $X.C involves a base node access by subscript. 
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(a) Original Tree 


$X 



2 6 6 
(b) Tree after $X.B = $X«C 
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(c) Tree of (a) after $X(2) = $X.C 
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(d) Tree of (a) after $X,B = 'ABC 


$X 



2 ABC 6 

(e) Tree of (a) after $X(2) = 'ABC 
F'ig. 2.4-4 Treatment of Base-Node Labels 
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Notice that the new label, "C," is copied from the structure 
referred to on the right-hand side. 

Figure 2.4-4 (d) shows a situation similar to (b) . Again, by 
specifying the base node by label, the programmer has made an 
assertion about which label is to appear on the node after ex- 
ecution of the statement. The fact that the expression on the 
right-hand side is a string expression has no special result 
here. Figure 2.4-4(e) on the other hand, deserves special at- 
tention. Because the node $X(2) was not specified by label, the 
existing label on this node is deleted. But the DUMMY node defined 
in the right-side expression has a null label. Therefore the ap- 
parent result of a statement like $X(2) = 'ABC' is to delete the 
existing base node label. As mentioned previously, recognition 
of those cases in which a dummy structure is created will assist 
the programmer in assuring that the desired operations are 
achieved. 

Another property of PLANS tree operations that should be well 
understood is the exclusivity of values and substructures. A 
node may have a null value or it may possess either a value or a • 
substructure, but it may never have both a value and a substruc- 
ture. Figure 2.4-5 illustrates this concept. In (b) , execution 
of $X.A = $Y(l) places a new value on the node $X.A, with the 
result that the previous substmioture of $X.A is deleted. Figure 
2.4-5 shows the converse case in which placement of a new sub- 
structure on the node $X.B deletes the previous vaZue of that 
node. 
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Figure 2.4-6 illustrates some tree assignments to previously 
nonexistent nodes. Figure 2.4-6(b) shows the tree of (a) as 
modified by the statement $X.D = 8. It should be noted that this 
statement has assigned a value and a label to the new node. Any 
time the referenced node does not exist, it is caused to exist as 
specified. If it was specified by label, this means the indicated 
label must be placed on the new node. 

Figure 2.4-6(c) shows the result of a statement in which a 
nonexistent node was specified by subscript. Because no label 
was used to indicate the node and the expression on the right has 
no label (it is a dummy node), the resulting node has a value, but 
no label. Figure 2.4-6(d) involves a new node with a label, but 
no value. In the figure this result was achieved by the state- 
ment LABEL($X(NEXT) ) = 'D'. However, because two prime (quote) 
marks together refer to the null character string, the same re- 
sult would be observed after execution of the statement $X.D = 

This statement places a null string on the node as a value, but 
that is completely equivalent to no value at all. 

Figure 2.4-6(e) shows what happens when an assignment is 
made to a node specified by a subscript that is too large. (It 
is, of course, only too large if the programmer did not want the 
result shown in the figure.) The programmer has stated that the 
fifth subnode of $X is to acquire the value 8. But this can only 
occur if, after execution of the statement, $X has at least five 
descendants. Because there were only three descendants before 
the statement was executed, two new nodes will be created. Only 
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(a) Original Tree 


$TREE 
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(b) Tree after $X.D = 8 


$TREE 
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(c) Tree of (a) after $X(NEXT) = 8 


$TREE 



2 4 6 

(d) Tree of (a) after LABEL ($X(NEXT)) = 'D' 


$TREE 



(e) Tree of (a) after $X(5) = 8 

Fig. 2,4-6 Assignments to Nonexistent Nodes 
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the latest of these newly created nodes is involved in a tree 
assignment statement; therefore, only the last node can acquire 
a label or a value. The remaining new node(s), in this case $X(4), 
will be null. 

In addition to the tree assignment statement, which usually 
vepT^cio&s the current contents of a specified node with a copy of 
the contents of another node, there are three other basic tree 
manipulation statements that perform somewhat similar functions. 
These are the GRAFT, INSERT, and GRAFT INSERT statements. Instead 
of simple replacement, the INSERT and GRAFT INSERT statements 
result in an insertion, with no deletion of information from the 
target tree. Instead of copying the information to be added to 
the target tree, the GRAFT and GRAFT INSERT statements 
the specified structure from its original location and move it to 
the target tree. Examples of these statements are shown in Fig. 
2.4-7 (GRAFT), 2.4-8 (INSERT), and 2.4-9 (GRAFT INSERT). In each 
case, the results of the statements should be compared with one 
another (they are parallel cases) and with the corresponding 
tree assignment statements in Fig. 2.4-1. 

Figures 2.4-l(b), 2.4-7(b), 2.4-8(b), and 2.4-9(b) show the 
effects of the statements $X(3) - $Y.C; GRAFT $Y.C AT $X(3), 

INSERT $Y.C AT $X(3); and GRAFT INSERT $Y.C AT $X(3); respectively. 
These statements all perform parallel operations, differing only 
by virtue of the special properties of the four statement types. 

It should be noted in particular that: (1) the tree assignment 
and GRAFT statements have the same effect (replacement) on $X-, 
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(b) Trees after GRAFT $Y.C AT $X(3) 
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(c) Trees of (b) after GRAFT $Y(LAST) AT $X.D 


$X $Y 



2 6 8 1 3 

(d) Trees of (c) after GRAFT $Y»E AT $X(2) 

Fi-g. 2,4-7 GRAFT Statements 
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(b) Trees after INSERT $Y.C AT $X(3) 


$X 



4 687 1 3 6 8 


(d) Trees of (c) after INSERT $Y.E AT $X(2) 
Fig. 2.4-5 INSERT Statements 
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(c) Trees of (b) after GRAFT INSERT $Y(LAST) AT $X.D 
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(d) Trees of (c) after GRAFT INSERT $Y.E AT $X(2) 


Fig, 2, 4-^9 GRAFT INSERT Statements 
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the target tree; (2) INSERT and GRAFT INSERT have the same effect 
(insertion) on $X; (3) the tree assignment and INSERT statements 
have no effect on $Y ; and (4) GRAFT and GRAFT INSERT have the 
saine effect (deletion) on $Y. It should also be noted that in- 
sertions are made at (or, if you prefer, before) the named node. 
The named node, and all others to the right, are **moved” one node 
to the right. 

Parts (c) of the four figures show additional parallel opera- 
tions of these four types. It should be observed that the INSERT 
and GRAFT INSERT operations of (c) result in two subnodes of $X 
that possess the same label. This is quite allowable, but the 
programmer should be aware that, if this occurs, the subsequent 
reference $X.D is a reference to only the firet such node. Either 
node can still be referenced by subscript, however, and a refer- 
ence of the form $X.ALL : (LABEL(ELEMENT = 'D')) would access att 
such nodes in one operation. 

Parts (d) of the four figures are included to make it -clear 
that in all cases an update to the target tree is performed. If 
the operation calls for a nonexistent node to be inserted or 
placed into a tree, a null node will result. The programmer can 
then test for the presence of a null node and, if desired, remove 
it. 

A final note on these four statements is particularily impor- 
tant, The GRAFT, INSERT, and GRAFT INSERT statements give the 
appearance of being more complex than the tree assignment state- 
ment, and the programmer may naturally assume that the latter is 
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more efficient and should be given preference whenever there is a 
choice. A little reflection on the underlying structural opera- 
tions will show that this is not true. The tree assignment and 
INSERT statements require the generation of a complete oopy of an 
existing structure. The execution cost of these statements (and 
the storage space required) is largely a function of the size of 
the structure that must be copied. The GRAFT and GRAFT INSERT 
statements, on the other hand, require only the alteration of a 
few pointers so that an existing structure can be moved, com- 
pletely intact, to another tree location. The execution cost of 
these statements is minimal, no additional storage is involved, 
and the cost is entirely independent of the size of the struc- 
ture that is moved. It cannot be overemphasized that GRAFT and 
GRAFT INSERT operations are not only very powerful, but are also 
very efficient! 

It is frequently necessary to remove a structure from a tree 
without placing it anywhere else. This simple deletion operation 
is accomplished by means of the PRUNE statement, illustrated in 
Fig. 2.4-10. The programmer simply specifies the node (or nodes) 
that, together with the associated substructure, is to be removed 
This operation allows the removal of undesired information from 
a tree. Tt may also be used, particularly as in (d) , to release 
computer storage that is no longer needed. It should be kept in 
mind while programming in PLANS that the programmer is really 
doing his own dynamic storage allocation (although PLANS handles 
all the details for him). When information is no longer needed. 
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(a) Original Tree 
$X 



(b) Tree after PRUNE $X.C 


$X 



(c) Tree of (a) alter PRUNE $X.C, $X.D 


$X 




Tree of (a) after PRUNE $X 



2.4-10 PRUNE Statements 



its storage can be reused, but only if the programmer releases 
it by means of a PRUNE statement, 

2.5 SPECIAL STATEMENTS 

The previous sections have discussed the basic dynamic tree 
manipulation capabilities of PLANS. These capabilities have been 
provided because they fulfill the essential requirements of sched- 
ule development and optimization programming. It should be ap- 
parent, though, that the capabilities of PLANS have been kept 
quite general in nature. This provides the flexibility that is 
needed to span a problem space as broad as that of scheduling. 
There remain, however, a small number of operations that are com- 
plex, and well-defined, that occur frequently in scheduling 
operations, and are difficult to handle with basic PLANS, These 
include ordering (sorting) and the generation of the combinations 
or permutations of a set of elements. Special statements have 
been provided in PLANS for the performance of these slightly more 
specialized functions. 

The ORDER statement is used to place the subnodes of a partic- 
ular node in ascending or descending order by a particular prop- 
erty they possess. If, for example, it is desired to order a 
group of payloads by weight, heaviest first, one might write 
ORDER $PAYL0ADS BY WEIGHT; or if they were to be ordered by 
length, shortest first, with ties broken by width, narrowest 
first, a statement of the form ORDER $PAYL0ADS BY -LENGTH, 

-WIDTH; would be appropriate. 
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Figure 2.5-1 illustrates a few of the properties of the ORDER 
statement. It should be apparent that an ORDER statement refers 
to a node, which, in turn, has subnodes to be ordered. Each sub- 
node has, at least potentially, the property or properties on which 
ordering is to occur. Ordering can be in either ascending or de- 
scending order. Figure 2.5-l(b) illustrates an ORDER statement 
in which the subnodes of the node $X are sorted into descending 
order on the basis of property Y. Note that, where the property 
in question is not possessed by a particular subnode (e.g., $X.C 
has no subnode labeled Y), a value of zero is assumed and the sort 
is performed accordingly. Note also that the normal ordering is 
descending; that is, the largest value occurs first. Thus, after 
execution of ORDER $PAYL0ADS BY WEIGHT, the heaviest payload will 
be $PAYL0AD(1). If ascending order is desired, the property name 
should be preceded by a minus sign (-) , as in (c) . 

PLANS provides a special DO statement for the generation of 
all the combinations or permutations of a set, taken a specified 
number at a time. Thus, for example, one can write DO FOR ALL 
COf^INATIONS OF $X TAKEN 2 AT A TIME, with the result that the 
DO-END group that begins with this statement will be executed 
once for each 2-element combination of the subnodes of $X. The 
particular combination that is relevant during an iteration of 
this DO-END group may be referred to within the DO-END group by 
the reserved tree name $C0MBINATI0N (or $PERMUTATION in the case 
of a DO FOR ALL PERMUTATIONS... statement). Figure 2.5-2 shows 
an example. $X has three elements with labels A, B, and C. 
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$x 



(a) Original Tree 



(b) First Iteration of DO FOR ALL COMBINATIONS 
OF $X TAKEM 2 AT A TIME 



(c) Second Iteration 



(d) Third Iteration 

Fig. 2.5-2 Automatic Genevationof Conbinations 
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The combinations of these elements taken 2 at a time are {A, B}, 

{A, C}, and {B, C}. It will be observed that the tree $C0MBINATI0N 
contains the node (and, in fact, the entire substructure) of $X.A 
and $X.B during the first iteration of the DO-END group, $X.A and 
$X.C during iteration two, and $X.B and $X.C during iteration 
three. The DO-END group is automatically exited before iteration 
four, just like the usual DO I = 1 TO 3 statement. The combina- 
tions (or permutations) are generated in standard (lexicographic) 
order. They, therefore, provide a mechanism for automatic gener- 
ation of combinations in standard sequence, and if a complete 
list of combinations of all sizes is needed, nested DO-END groups 
of the form 

DO I = 1 TO NUMBER($X); 

DO FOR ALL COMBINATIONS OF $X TAKEN I AT A TIME; 

END; 

END; 

can be used. 

In order to provide efficient execution of these commands, 
the tree $C0MBINATI0N (or $PERMUTATI0N) is not actually generated. 
The existing tree (in the example, $X) from which the combinations 
are generated is actually used. $C0MBINATI0N is merely a conven- 
ient way of referencing only those subnodes that are involved in 
the current combination. Thus, although $X(l) is the element A, 
$X(2)is B, and $X(3) is C, during the second iteration 
$C0MBI NATION ( 1 ) is the element A, $C0MBINATI0N (2) is the element 
C, and there is no $C0MBINATI0N (3). The important point to 
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understand is that modifications made to $C0MBINATI0N are actually 
being made to $X. Furthermore, no structural modifications are 
allowed at the base node level. In the example, one could change 
the value of $C0MBINATI0N(2) or add a substructure to it, but no 
immediate descendants of either $X or $C0MB I NATION may be added, 
deleted, or reordered inside the DO-END group. 

2.6 A SIMPLE EXAMPLE 

To assist the reader in gaining greater intuitive feeling for 
PLANS dynamic tree operations, a simple (but useful) PLANS program 
will now be considered in some detail. The program is called 
ORDER_BY__PREDECESSORS, and its function is to place a list of jobs, 
any one of which may have any of the others as a required prede- 
cessor, into an order such that the predecessors, if any, of each 
job occur earlier in the list than does the job itself. This 
function, fairly difficult in most programming languages, is very 
simple and straightforward in PLANS. While there are many func- 
tionally equivalent ways to write this program, one of the sim- 
plest and most efficient is as follows. 

OROER^Y^PREDECEsSORSi procedure (SJOBLIST* $0R0ERE0_LI^T) \ 
DECLARE STEwPf *NAMEJ.IST LOCAL I 

LOOP* 

graft SJOBLIST, first* <ELEMENT, predecessor SUBSET OF SNAME^LIST) 
AT STEMP I 

IF STEMP IDENTICAL TO SNUlL THEN RETURN I 
SNAME^LIST(nEXT) « LABEL (STEMP) I 
graft STEMP AT SOROERED^LIST (NEXT ) « 

GO TO LOOP I 

END OROER^BY^REOECESSORS I 
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Let us consider the execution of this program for a simple data 
case. 

Notice, first (line 1) , that the program is a called procedure 
with the explicit parameters $J0BLIST and $ORDERED_LIST . The call- 
ing program will initialize these trees as desired. Rather than 
attempting to reorder $J0BLIST, ORDER_BY_PREDECESSORS will move 
the jobs, one at a time, from $J0BLIST to $ORDERED_LIST; so that 
the $0RDERED_LIST will become a correct ordering of the jobs 
that were originally in $J0BLIST. $J0BLIST, on the other hand, 
will be returned null, assuming all goes well. Upon return from 
DRDER_BY_PREDECESSORS , then, the calling program will use 
$ORDERED_J_IST where $J0BLIST was used before (or will GRAFT 
$ORDERED_LIST AT $J0BLIST) after checking $J0BLIST for a null 
condition. 

In line 2, $TEMP and $NAME_LIST are declared to be local 
trees. This means two things: (1) any use of these tree names 

within this procedure is entirely local, and will not affect trees 
of the same name outside this procedure, and (2) each time 
ORDER_BY_PREDECESSORS is called, $TEMP and $NAME_LIST will be 
initially null, and any storage they use will be made available 
for reuse upon return without any other action on the programmer's 
part. 

Let us assume the initial data shown in part (a) of Fig. 2,6-1. 
SJOBLIST describes a predecessor network in which job B has no 
predecessor jobs, jobs C and D must each be preceded by job B, and 
job A must follow both C and D, The diagram shows only information 
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SOOBLIST $ORDERED_LIST $TEMP $NAME_LIST 

000“ 



PREDECESSOR 


(a) Initial State 


SJOBLIST 



$ORDERED_LIST $TEMP $NAME_LIST 

b Ob O" 


(b) After GRAFT $J0BLIST. FIRST: (ELEMENT. PREDECESSOR SUBSET OF $NAME__LIST) 
AT $TEMP 


SJOBLIST 



$OROERED_LIST $TEMP $NAME_LIST 

b 


PREDECESSOR 


(c) After $NAME_LIST(NEXT) = LABEL($TEMP) 

SJOBLIST $ORDERED_LIST $TEMP $NAME_LIST 

o 




(d) After GRAFT $TEMP AT $ORDERED_LIST{NEXT) 
Fig. 2.6-1 ORDERLY _PREDECESSOnS: ITERATION 1 



essential for present purposes. However, it is assumed that 
other information about each job (e>g*» duration, resource require- 
ments, etc) is also present. Because we can access predecessor 
information by label without regard for its ordinal position, any 
other information about these jobs is irrelevant, so long as the 
label PREDECESSOR is used only with the meaning assumed here. 
$ORDERED_LIST is assumed to be null. Ordinarily this condition 
will be assured by the calling program. $TEMP and $NAME LIST 
are automatically initialized to a null condition. 

Consider now the effect of the GRAFT statement of line 4 on 
these trees. This statement specifies that a particular job Is 
to be removed from $J0BLIST and placed at $TEMP. The job to be 
selected is to be the first job whose predecessor set is a subset 
of $NAME_LIST. $NAME_LIST will be used to collect the names of 
the jobs in $ORDERED_LIST, so that the SUBSET OF relation can be ' 
used to automatically determine whether the predecessor require- 
ment of a particular job is satisfied. Because $NAME__LIST is 
presently null, the only job of $J0BLIST that can possibly satisfy 
the conditional access is a job that has no predecessors. Note 
that job B fulfills this requirement, and that it is not nec- 
essary in this case that a node labeled PREDECESSOR even appear 
under job B because a nonexistent node has all the properties of 
a null node, including null subnode structure. Job B therefore 
satisfies the conditional access, and is removed from $dOBLIST 
and placed at $TEMP, as shown in Fig. 2.6-l(b). While the diagram 
includes no subnodes of the job B base node, that node and all its 
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subst'PuotuP& have replaced the previously null root node of the 
tree $TEMP. 

The statement of line 5 now tests for failure of the previous 
GRAFT statement. In the event that no subnode of $J0BLIST sat- 
isfied the access condition, $TEMP will now be null, and detection 
of this condition can be used to trigger return from ORDER BY_ 
PREDECESSORS, in the present case, however, $TEMP is not null. 

A node is defined as null only if it either does not exist or has 
both a null value and a null label. Regardless of any substruc- 
ture, the node $TEMP now has the label "B" and is therefore not 
null, and no return occurs. 

The statement of line 6 is therfore executed, placing the 
name of the job that was found into $NAME__LIST. Several things 
should be noticed here. Since $NAME_LIST is currently null, 
$NAME_LIST(NEXT) is equivalent to $NAME_LIST( 1) . LABEL($TEMP) 
is a character string. Therefore, a dummy node is established, 

with a null label, and placed at $NAME LIST(NEXT). The statement 

causes the job name, "B" to be a value of $NAME_LIST( 1) , so that 
subsequent comparisons of $NAME_LIST and PREDECESSOR nodes will 
find job names as values in both places. 

Finally, line 7 is executed, moving the found job, with all 
descriptive information, from $TEMP to the next available position 
in $ORDERED_LIST. Note that $TEMP again reverts to a null condi- 
tion. Trees always have root nodes, although they may be null. 
Thus, the removal of the node labeled "B" causes another (null) 
node to be placed at $TEMP . 
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The program has now found the first job that can be executed 
and has moved it into $ORDERED_LIST. Another iteration is there- 
fore initiated (line 8) by jumping back to LOOP. 

' Figure 2.6-2 shows the tree manipulations that occur during 
iteration 2. The initial state, part (a), is the same as that at 
the end of iteration 1. The conditional GRAFT statement of line 
4 again searches for a job whose predecessors, if any, are all 
named in $NAME_LIST. Since $NAME_LIST now contains the job name 
”B," either a job with no predecessors or a job with only the 
predecessor "B" will satisfy the access condition. The first 
such job now in $J0BLIST is job C, which is therefore grafted at 
$TEHP [Fig. 2.6-2(b)]. Because $TEMP is not null, no return is 
made at line 5. 

The statement at line 6 places the name of the found job at 
the next available subnode of $NAME_LIST. As shown in Fig. 
2.6-2(c), $NAME__LIST now contains the names of the two jobs (B 
and C) found so far, $TEMP is grafted (line 7) onto the next 
available position of $ORDERED_LIST [part (d)], which now con- 
tains all the information about jobs B and C (in that order) that 
was originally in $J0BLIST. Only the jobs not yet placed in 
$ORDERED_LIST still remain in $J0BLIST. Line 8 then causes another 
iteration to begin. 

This process is repeated two more times, once for job D and 
once for job A, with the result shown in Fig. 2.6-3(a). All jobs 
have now been moved to $0RDERED_L 1ST . When the conditional GRAFT 
statement of line 4 is executed, no job will be found, and a null 
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(b) After GRAFT $JOBLIST. FI RST: (ELEMENT. PREDECESSOR SUBSET OF $NAME_LIST) AT $TEMP 



(d) After GRAFT $TEMP AT $ORDERED__LIST(NEXT) 



Fig. 2,6-2 OBDER^:i_PREDECESSOIiS: ITERATION 2 


57 



Fig. 2.6-Z 


$JOBLIST $ORDERED_LIST $TEMP $NAME_LIST 



B CD 

(a) After Iteration 4 


$J0BLIST $0RDERED LIST $TEMP $NAME_LIST 



B BCD 

(b) After GRAFT $J0BLI$T. FIRST : (ELEMENT. PREDECESSOR SUBSET OF $NAME_LIST) AT $TEMP 


Fig. 2.6-3 OHDEH_Byj’REDECESSORS: ITERATION S 



node will be placed on $TEMP (b) . This condition allows the re- 
turn to occur in line 5. $J0BLIST and $ORDERED_LIST will be re- 
turned to the calling program, while $TEMP and $NAME_LIST will be 
pruned automatically in order to free their storage. 

It may occur to the reader to question the use of $TEMP be- 
cause a found job could be grafted (line 4) directly at 
$0RDERED_LIST(NEXT) . However, this would require two additional 
accesses to $0RDERED_LIST(LAST) , one to test for a null condition 
(line 5) and one to extract the label (line 6) . In addition, be- 
fore exit, the extra null node that would have been grafted onto 
$ORDERED_LIST would have to be removed. It should always be borne 
in mind that node access time is a function of the number of sub- 
nodes that must be scanned (left to right) before the desired 
node is found. Thus, $TEHP is more efficient to access than is 
$ORDERED_LIST(LAST) , and the difference is more pronounced as the 
$ORDERED_LIST grows. Because GRAFT statements are very efficient, 
the use of $TEMP is preferable here. 


/ 
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3.0 System Operations and 
Problem Modeling 




3.0 


SYSTEM OPERATIONS AND PROBLEM MODELING 


The successful computer-aided solution of scheduling and re- 
source allocation problems requires an integrated af>proach using 
three conceptual and analytical tools; (1) a computer programming 
language, (2) a descriptive model or representation of the system 
and its operations , and (3) problem solving approaches or decision 
making rules (algorithms) . The scheduling language (PLANS) speci- 
fied during this study supplies the first of these tools. The 
special features of PLANS that facilitate this effort have been 
described extensively in Chapter 2.0 of this volume as well as in 
Volumes I and III. A library of routines (modules) that perform 
operations model and algorithm functions is also specified in 
Volume III. This section discusses the use of the PLANS modules 
for problem description and solution. 

3.1 A GENERIC SCHEDULING OPERATIONS MODEL 

The scheduling modules like the language itself are applicable 
to complex systems in general and are not specific to the 'Space 
Shuttle. The reasons for, and expected benefits of, a generic ap- 
proach are discussed in Volume I and are not repeated here. It is 
appropriate however to raise the question, "What are the conse- 
quences of using a generic modeling approach for the potential 
user of the PLANS programming system?" 

3.1.1 Generic Modeling Consequences for the User 

One price the PLANS user must pay to benefit from the general 
problem modeling approach developed by this study, is to learn a 
generic system description nomenclature. He must also learn to 
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recognize the functional elements, physical resources, and oper- 
ational processes (activities) of his system and their interrela- 
tionships within the operations model framework. If he does this, 
he will gain, from the following pages, an understanding of how 
various techniques can be applied effectively using PLANS. 

Before a generic approach to operational system and problem 
modeling is described, two important points should be stated. 

1) There is no substitute for knowledge of the system that is to 
be modeled (and scheduled) ; 

2) The automation of systems scheduling and resource allocation 
should not be accepted on an a -pTiovi basis without qualifica- 
tions. 

The significant increase in capabilities due to the power of the 
TlANS language and module library should not promote the miscon- 
ception that the user will not need to think about his problem 
applications in depth. 

Because a generic modeling approach was used to develop speci- 
fications, the PLANS module user will not find an input data struc- 
ture including explicit labels such as, PAYLOAD NAME, PAYLOAD 
LENGTH, ORBITER SERIAL NUMBER, or ORBITER PAYLOAD BAY LENGTH. 

With the generic model , it is up to the user to know that these 
input items, when expressed genetically, have the form RESOURCE. 
TYPE; NAME; PARAMETER; CLASS; etc. Similarly he does not find 
BRIEF CHEW or CHECKOUT PAYLOAD, but finds instead PROCESS: NAME,; 
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DURATION; TYPE; RESOURCES GENERATED; RESOURCES DELETED; and RE- 
QUIRED SOURCES; etc. All of these generic elements are de- 
scribed and properly related to each other in Section 3.4. 

Note that nothing prevents the use of PLANS to program models 
and algorithms with explicit RESOURCE or PROCESS labels , if the 
user is willing to trade the flexibility and other benefits of 
the generic approach for the presumed advantages of explicit 
labels in the basic program structure and logic. However, it 
should be understood that although generic labels are used in a 
basic program code, the data for that code will contain the 
problem-specific data in explicit terms and thus will provide 
descriptive detail in a user-oritnted format. This compensates 
. for the use of generic labels in the program logic while pre- 
serving the flexibility of that logic. 

Even more significant than the perception of system elements 
in terms of generic elements, is the choice of correct resources 
and processes for the model and the determination of the appro- 
priate level for resource and process description. Selection of 
these items requires a knowledge of the sytem as well as a knowl- 
edge of the approach that will be used to obtain a solution. 

3.1.2 Elements of the Generic Scheduling Operations Model 

Drawing upon the Shuttle system as an example, it can be 
recognized that the description of Shuttle operations is char- 
acterized mainly by interrelated sets of activities or processes 
that integrate various physical system resources to achieve a 
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final launch configuration. This configuration must, of course, be 
capable of achieving specific objectives. Because scheduling is 
of primary concern, the parameters used to describe system opera- 
tions consist of a set of pi^ooesses that require specific resources 
for particular time intervals. The association of specific re- 
sources with a time interval constitutes a schedule unit, i.e., a 
basic element of a schedule. The concept of using processes to 
associate resources into schedule units is illustrated in Fig. 

3.1- 1. 

The recognized technique to describe relationships between 
activities or events is the network or flow diagram. Figure 

3.1- 2 is a sample diagram that illustrates the flow of Shuttle 
mission operations on a top-level basis. Such diagrams visually 
depict one or more operations sequences in terms of predecessor- 
successor relationships and also contribute to the recognition 
of more general temporal relations . 

A fundamental concept of the generic operations model is 
that for scheduling and resource allocation purposes an opera- 
tional system can be described in terms of RESOURCES , PROCESSES 
and OPERATIONS SEQUENCES. This concept leads directly to the 
specification of standard PLANS data structures that contain 
descriptive information arranged with the same logical separa- 
tion. The operations model data structures are described in 
detail in Section 3.5. 
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Fig. 3.1-1 
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Fi-g. 3 . 1-2 Sample Network Flew Diagram for System Operations Description^ Shuttle Mission 




The use of ghe generic op rat ions model concept requires not 


only an understanding of the conventions for describing the sys- 
tem to be scheduled, but also the conventions used to establish 
any procedural logic associated with the model. In particular, 
a conceptual framework is needed for understandings how descrip- 
tive information is communicated to decision logic algorithms 
to solve a scheduling problem. The roles of the model and the 
algorithm may be interpreted in terms of a dialog; the algorithms 
request information about a system and its operation on which to 
base a scheduling decision and the operations model supplies the 
data. Any functions that must be performed to supply the algo- 
rithms with appropriate model information can be regarded as 
operations model functions. A typical integration of operations 
model functions and algorithm functions is shown in Fig. 3.1-3. 
Annotations on the figure relate to the OSARS (NASA-MPAD) pro- 
gram currently used to assign resources to flights. 

The logical separation between operations model functions and 
algorithm functions serves to define logic boundaries for the 
PLANS module library. The user who perceives this distinction 
and who uses the descriptive conventions of the generic opera- 
tions model will find that the PLANS module library will provide 
many powerful capabilities that are easily incorporated into his 
PLANS program. 
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OPERATIONS MODEL 

TIME-PROGRESSIVE SOLUTION ALGORITHM 
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Fig. 3,1-3 Operations Model/ Solution Algorithm Interface Example with OSABS Annotation 






3.2 Problem Types Accommodated by 
the Operations Model 



3.2 Problem Types Accommodated by the Operations Model 



PROBLEM TYPES ACCOMMODATED BY THE OPERATIONS MODEL 

To assist the reader whose interest is in a special problem 
or class of problems, this section states some typical problems 
without detail, characterizes those problems in terms of the 
operations model described in Section 3.4, and suggests the sub- 
sections where modeling details can be found. This information 
is provided in Table 3.2-1. Each problem type in Table 3.2—1 
could require any or all of the descriptive generality contained 
in Section 3.4. The reader should not assume that the subsec- 
tions referenced contain the only relevant material. 
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Table 3,2-1 

Use of PLANS Generic Operations Model for Describing Typical Problem Classes 


Problem Class 

Typical Plans 
Operations Model 
Characterization 

Sections of Volume II 
Giving More Detail 

Paragraph 

Page 

Project Planning 

Predecessor networks. 

3.4.1 thru 3.4.6 


& Control 

splittable jobs, 

3.6 



pooled resources 



Crew Activity 

General temporal 

3.4.7 


Timelining 

relations with 

3.4.10 



item-specific 

3.4.11 



resources 



Cargo 

Item-specific 

3.4.7 


Cent alner izat ion 

resources, quasi- 

3.6 



enumerative 




solution techniques 



Facility Utilization 

Predecessor network 

3.4.1 



with item-specific 

3.4.2 



resources 

3.4.7 


Transportation System 

General temporal 

3.4.3 


Scheduling 

relations with 

3.4.10 



pooled resources 



Plant Production 

Predecessor networks 

3.4.1 thru 3.4.6 


Scheduling 

with pooled resources 

3.6 


Computer Job 

Splittable jobs 

3.4.1 thru 3.4.5 


Scheduling 

pooled resources 



Payload Compatibility 

Item-specific resources. 

3.4.7 


Grouping 

quasi-enumerative 

3.6 



solution techniques 



Personnel Resource 

Pooled resources. 

3.4.3 


Allocation 

explicit descriptors 

3.4.12 



for pooled resources 



Experiment Selection 

Item-specific 

3.4.3 


& Equipment Allocation 

& pooled resources 

3.4.7 
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3.3 PLANS Library AAodule 


ay 


3.3 PLANS Library Module 


3.3 


PLANS LIBRARY MODULES 


Functional specifications for a library of routines, called 
modules, have been developed in parallel with the specifications 
for the programming language (PLANS) . The contents of such a 
library of modules have been integrated using the generic opera- 
tions model concepts described in Section 3.1. Decisions on what 
level of detail to include are necessarily somewhat arbitrary and 
based on nonquant if iable judgments. However, the current modules 
have resulted from a functional analysis of many classes of schedul- 
ing problems using the following criteria: 

1) Each module in the current specification should be limited to 
a single logical function. Although it is possible to group 
several of the specified modules together, based on high- 
level functional similarity, to do so either restricts flexi- 
bility or increases the computational inefficiency of the 
functions represented. Therefore, the modules specified for 
the program library perform a single separable logical func- 
tion. 

2) Each module specified performs a function that is common or 
likely to occur in developing typical scheduling software. 
Although this criteria seems self-evident, it is easy to con- 
ceptualize numerous modules that are applicable to only an 
infrequent special case or that are required only in unen- 
lightened or highly encumbered approaches to a scheduling 
problem. In those cases where a function would be required 
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by one approach to a problem but not required by an alterna- 
tive and clearly superior approach, a module to perform that 
function has not been specified. 

3) Each module specified does not contain judgments or decision- 
making logic for which the criteria are open to opinion. For 
example, no modules assume specific economic models, queuing 
service policies, or criteria for resolving resource alterna- 
tives. There are no approximations of dependent variables by 
polynomials or piecewise-linear functions buried in any module 
logic. These judgmental matters have been considered too 
problem-dependent and inflexible for an initial library speci- 
fication. Because of the criterion for functional simplicity 
and separability [criterion 1) above], the specified opera- 
tions model modules perform elementary operations and gener- 
ally return information on which decisions can be made rather 
than the decisions themselves. The modules that are specified 
as algorithms make simple decisions based on quantitative cri- 
teria that are easily perceived by the user. A clear dis- 
tinction has been attempted between simple decision-making 
modules (i.e., algorithms) and information providing modules 
(the operations model) so that all of the latter are equally 
applicable whether exercised interactively by a user making 
real-time decisions or in a batched system design where 
algorithm modules make the scheduling decisions. 
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The criteria stated are appropriate for specifying the first 
modules to be placed in a program library because flexibility and 
commonality of application are prime considerations*. It is not 
intended to imply, however, that future additions to the module 
library should be restricted by these criteria. Analyses are 
currently underway that will lead to the specification of higher- 
level modules. Such modules will combine the functions of many 
of the currently specified modules through special purpose exe- 
cutive logic. Special attention is being paid to methods for 
translating generalized problem formats into the more restrictive 
structures required by existing solution methodologies. 

Table 3.3-1 contains a brief description of the modules speci- 
fied in this study. Detailed functional descriptions for all 
modules are provided in the sections of Volume III indicated in 
the table. The reader who is interested in the use of a partic- 
ular module should refer to the sections indicated in the table. 
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Table 3.3-1 Svmnary of PLAJiS Module Library Contents 




Volume II 
References 


Module Name 

Brief Description of Intended Usage 

Paragraph 

Page 

volume m 
Specifications 

DURATION 

Calculates the duration of any 
standard (simple or multiple) 
interval 



2.4.1 

ENVELOPE 

Calculates an interval that is the 
smallest cover of a given standard 
(simple or multiple) interval 



2.4.2 

INTERVALJJNION 

Calculates a standard interval that 
is the union of two standard intervals, 
i.e., all points in the output standard 
interval are in one or both of the 
input standard intervals. 



2.4.3 

INTERVALJNTERSECTION 

Calculates a standard interval that 
is the intersection of two standard 
intervals, i.e., all points in the 
output standard interval are in both 
the input standard intervals. 




FIND_MAXIMUM 

Finds the maximum value in a numeric 
set and all the elements that have 
chat maximum value. 



2.4.5 

FINDJ1INIMUM 

Finds the minimum value in a numeric 
set and all the elements that have 
that minimum value. 



2,4.6 

CHECK_FOR_PROCESS_ 

DEFINITION 

Checks for input data consistency, 
i.e., checks that all operations 
sequences named in $OBJECTIVES are 
defined in $OPSEQUENCE and that all 
processes in those operations se- 
quences or in $OBJECTIVES are defined 
in $PR0CESS. 



2.4.7 

GENERATE_JOBSET 

Creates individual jobs for each 
occurrence of a process specified 
explicitly or via an operations 
sequence in $OBJECTIVES. Merges 
Information contained in $OBJECTIVE, 
$OPSEQUENCE , and $PR0CESS into a 
tree called $J0BSET. Jobs in 
$J0BSET are ready for the decision 
algorithms to make explicit assign- 
ments. 

4.3 


2.4.8 

CHECK_EXTERNAL_ 

TEMP_RELATIONS 

Identifies temporal constraint 
violations that would occur if two 
sets of job assignments were merged. 
Useful for checking if a potential 
assignment will be consistent with 
existing assignments. 

3.4.10 


2.4.9 

CHECK_INTERNAL_TEMP_ 

RELATIONS 

Identifies temporal constraint 
violations that exist within a set 
of job assignments. Useful in find- 
ing constraint violations after 
multiple assignments have been made 
with temporal constraints relaxed. 

3.4.10 


2.4.10 

CHECK_ELEMENTARY_ 

TEHP_RELATION 

Checks satisfaction of a single 
binary temporal relation given 
specific assignments for the two 
jobs named in the temporal relation. 

3.4.10 


2.4.11 
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Table 3.3-2 (cant)- 




Volume II 
References 

Nodule Name 

Brief Description of Intended Usage 

Paragraph 

NEXTJET 

■ 

Determines a set of specific resource 
items to meet the requirements of a 
job and permit the earliest possible 
execution of that job. 

Determines future times the job 
requirements can be met with any 
combination of appropriate resource 
types. 

4.4 

RESOURCE_PROFILE 

Determines the profile of a resource 
pool over a given time interval for 
both 'normal' and 'contingency' levels. 
Determines the profile of the assigned 
portion of a pool and gives the jobs 
to which the resources are assigned . 

4.3 

P00LED_DESCRIPT0R_ 

COMPATIBILITY 

Determines if a single assignment 
of a job using pooled resources 
with explicit descriptors is (will 
be) compatible with existing de- 
scriptors for resources required 
by that job. 

3.4.12 

DESCRIPTOR_PROFILE 

Determines the descriptors for an 
item-specific resource that are 
valid after a set of jobs involving 
those resources have been scheduled. 
Uses the assignment information in 
$RES0URCE to determine the descriptor 
set at a particular time. 


UPDATE_RESOURCE 

Records the scheduling of a schedule 
unit (job) by writing assignments in 
$RES0URCE for all resources used 
in the schedule unit . 

4.4 

WRITE_ASSIGNMENT 

Writes a single assignment for a re- 
source and adds the assignment node 
in chronological order in $RES0URCE, 

4.3 

UNSCHEDULE 

Deletes assignments from $RES0URCE 
for all resources associated with a 
specified job to be deleted. 


C0MPATIBILITY_SET_ 

GENERATOR 

Enumerates all compatible subsets of 
an input set using externally 
supplied compatibility criteria. 

3.6 

FEASIBLE_PARTITION_ 

GENERATOR 

Generates all sets of integers with 
a given number of elements that 
sum to a given total. Useful in 
fathoming many branches in enumer- 
atlve heuristics. 

3.6 

PROJECT_DE COMPOSER 

Identifies at subprojects within 
a project description; i.e., finds 
subnetworks that contain all pre- 
decessors and successors of its 
member activities. 

3.4.1 

3.6 

REDUNDANT_ 

PREDECESSOR^ 

CHECKER 

Identifies and eliminates redundant 
specifications of predecessors in 
$J0BSET; e.g. , in A < B B < C 

A < C, the last specification is 
redundant . 

3.4.1 

3.6 













Table Z.Z-1 (oont) 


Module Name 


CRITICAL_PATH__ 

CALCULATOR 

PREDECESSOR_SET_ 

INVERTER 


NETWORK CONDENSER 


CONDENSED_NETWORK_ 

MERGER 


NETWORK ASSEMBLER 


CRITICAL_PATH_ 

PROCESSOR 


NETWORK EDITOR 


CHECK_DESCRIPTOR_ 

COMPATIBILITY 


ORDER BY PREDECESSOR 


RESOURCE ALLOCATOR 


RESOURCE LEVELER 


Volume II 
References 

Brief Description of Intended Usage Paragraph 


Calculates early and late start and 3.4.2, 3.4.4 
finish times as well as total and 3.6 

free float in a network of jobs. 4.3 

Creates, from a set of jobs with 3,4.4 

predecessors, an equivalent set of 3.6 

jobs with successors. Used in 
critical path analyses. 

Eliminates activities (jobs) from 3.4.2 

a network leaving only events linked 
by critical delays as branches. 

Merges two condensed networks into a 3.4.2 
single composite condensed network, 
and computes the critical path data 
for the composite network. 

Assembles a master network from sub- 3.4.2 
networks with interfacing events. 3.4.4 

The relations between the subnet- 3.4.6 

works may be more general than those 3.6 
describable by nesting operations 
sequences . 

Condenses, merges and computes 3.4.2 

critical path data for a master net- 3.4.4 
work. Performs executive function, 3.6 

which calls NETWORK_CONDENSER, 

CONDENSED JETWORKJIERGER, and 
CRI TI CAL_P ATH_CAL CULATOR .. 

Identifies and eliminates both 3.4.1 

redundant predecessors and cycles 
specified in the specification of 
precedence networks. Performs 
executive function, which calls 
ORDER_BY_PREDECESSOR and REDUNDANT 
PREDECESSORJLIMINATOR. 

Determines if a single assignment 3.4.11 

of a job using item-specific resources 
with explicit descriptors is (will be) 
compatible with existing descriptors 
for resources required by that job. 

Identifies scheduled jobs that change 
the incompatible descriptors. 

Produces a list of jobs where all 3.4.1 

jobs appear in the list only after. 3.6 

all their predecessor have appeared; 4.1 

i.e,, produces a nonunique tech- 
nological ordering. 

Allocates resources to jobs to 3.4.6 

satisfy all resource constraints 3.6 

and heuristically produce a minimum 4.3 

duration schedule. Uses project 
scheduling problem model. 

Reallocates resources to smooth the 3.4.6 
usage of resources while maintaining 3.6 
schedule constraints. Uses project 
scheduling problem model. 


Volu 
Page Spec 


2.4.23 


2.4.24 



2.4.25 


2.4.26 


2.4.27 


2.4.28 


2.4.29 


2.4.30 


2.4.31 


2.4.32 


2.4.33 
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Volume II 
References 



Module Name 

Brief Description of Intended Usage 

Paragraph 

Page 

Volume III 
Specifications 

HEURISTIC_SCHEDULING_ 

PROCESSOR 

Performs both time-progressive re- 
source allocations/job scheduling 
and resource leveling. Performs 
executive function for RESOURCE 
ALLOCATOR and RESOURCE_LEVELER.~ 
Uses project scheduling problem 
model. 

3.4.5 

3.4.6 

3.6 


2.4.34 

GUB_LP 

Solves special-purpose linear 
programs that arise as simplified 
models of transportation, distri- 
bution, and multi-item scheduling 
problems. Uses generalized upper 
bounding LP format. 

3.6 


2,4.35 

MIXED_INTEGER_ 

PROGRAM 

Solves linear programs that contain 
both continuous and integer-valued 
decision variables. 

3.6 


2.4.36 

PRIMALJIMPLEX 

Solves linear programs that arise in 
the process of solving scheduling 
and resource allocation problems 
with multi-level algorithms. 

3.6 


2.4.37 

DUAL_S IMPLEX 

Solves dual linear programs that 
arise as a result of the structure 
of multi-level scheduling and re- 
source allocation algorithms. Uses 
primal simplex format. 

3.6 


2.4.38 

INTEGER^PROGRAM 

Solves the linear form of the binary 
decision making problem. 

■ ■ ■■■■■ - ■ 1.— 

3.6 


2.4.39 









3.4 Problem Description Using the 
Operations Model 



3. A PROBLEM DESCRIPTION USING THE OPERATIONS MODEL 

This section classifies scheduling problem descriptions. The 
material is presented in sequence from the simplest scheduling 
problem descriptions to the most complex as illustrated in Fig. 
3.4-1. Each section briefly discusses an additional generality 
to a problem description that results in a more complex problem 
from the point of view of programming logic and/or solution method. 
The sequence of presentation is a logical one, but the section 
does not require beginning-to-end reading to enable the identifi- 
cation of descriptive characteristics appropriate for any particu- 
lar problem. Furthermore, the presentation sequence does not 
imply that any specific problem description will include all gen- 
eralities to the left of a particular point in Fig. 3.4-1. 
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Fig, 3.4-1 


JOBS AND THEIR RELATIONSHIPS TO OTHER JOBS 



RESOURCES AND THEIR RELATIONSHIPS TO JOBS 
Fig. 3.4-1 Problem Description Using the Operations Model 


3. 4. 1 Simple P rederassor Networks 







3,4,1 Simple Predecessor Networks 

The simplest scheduling problem model permits only simple 
predecessor relationships between jobs. Job A is a predecessor 
of Job B if, and only if, Job A is completed at a time before or 
equal to the start of Job B. This simple relationship permits 
an entire precedence network to be completely defined by a list 
of jobs with an associated list of predecessors for each job. 

A simple precedence network is illustrated in Fig. 3. 4. 1-1. 

The information contained in the network diagram of Fig. 3.4-1 
is shown in Table 3. 4. 1-1. 

TahZe 3. 4. 2-1 Basic Information of a Predecessor Network 


Job 

Predecessors 

Mate External Tank 
to SRBs 

— 

Mate Orbiter to 
External Tank 

Mate External Tank to SRBs 
Perform Payload Operations 

Refurbish Launch Pad 

— 

Perform Payload 
Operations 

— 

Perform Crew 
Training 

Perform Payload Operations 

Launch 

Perform Crew Training 

Mate Orbiter to External Tank 

Refurbish Launch Pad 

Refurbish Launch Pad 

. — 





Elementary operations can be performed with the simple 
precedence network defined. If, in the example, "Perform Payload 
Operations" were given as a predecessor of "Launch," the specifi- 
cation is redundant as long as "Mate Orbiter to External Tank" 
is specified as a predecessor of "Launch." In more complex 
networks, redundant specifications are easily constructed. There- 
fore, the module library includes a module, REDUNDANT_PREDECESSOR_ 
CHECKER, that will detect and remove a redundant specification. 

It is also common to inadvertently specify a loop in a network. 
This is illustrated below: 

JOB A 

PREDECESSOR 
JOB B 

JOB B 

PREDECESSOR 
JOB C 

JOB C 

PREDECESSOR 
JOB A 

The module library contains a module NETW0RK_EDIT0R that detects 
and eliminates cycles or loops in a network. 

A list of jobs and their associated predecessors that consti- 
tute a precedence network may be ordered so that each job appears 
on the list only after all its predecessors have appeared. The 
simple illustration network can be presented in such an ordering 
as shown in Table 3. 4. 1-2. 
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Table 2. 4, 1-2 

OTdeT'ing HeWovk Jobs by 

Predeoessors 


Perform Payload Operations 
Mate External Tank to SRBs 
Refurbish Launch Pad 
Perform Crew Training 
Mate Orbit er to External Tank 
Refurbish Launch Pad 
Launch 

Obviously this ordering is not unique, it represents, however, 
a sequence in which jobs could be completed without violating 

any precedence constraints. The module ORDER BY PREDECESSORS 

produces a proper ordering. An ordering that produces the se- 
quence in which all predecessor relationships are satisfied is 
called a teohnological ordering. 
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3.4.2 Networks with Job Durations 
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3.4.2 Networks with Job Durations 


If job durations are added to the network information, addi- 
tional computations can be made. The minimum time schedule can 
be determined for this problem model. All paths in the network 
for which no unscheduled time is possible in the minimum time 
schedule are called critical paths. All other paths contain 
slack, i.e., time intervals associated with one or more jobs 
within which the start times may be altered without causing a 

o 

delay to the minimum time schedule. A simple illustration of 
these definitions is shown in Fig. 3. 4. 2-1 . All CPM (Critical 
Path Method) and PERT (Project Estimation and Review Technique) 
analyses are based on simple networks containing jobs with fixed 
durations and predecessor sets. The PLANS module library con- 
tains five modules that perform computations on CPM problem 
models. They are: 

1) CRITICAL_PATH_PROCESSOR 

2) CRITICAL_PATH_CALCULATOR 

3) NETWORK_CONDENSER 

4) CONDENSED_NETWORK_MERGER 

5) NETWORK_ASSEMBLER 

The first is an executive routine and the second calculates param- 
eters for a simple network. The others provide'^computations 
associated with more general networks that are addressed in a 
subsequent section. 
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3.4.3 Simple Resource Pools 
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RESOURCES AND THEIR RELATIONSHIPS TO JOBS 


3.4.3 Simple Resource Pools 

If each Job in the problem model requires a specified number 
of resource units as illustrated in Fig. 3. 4. 3-2 , then the net- 
work analysis becomes a project scheduling problem. Stated simply, 
project scheduling is network scheduling plus resource/ job relation- 
ships. In project scheduling, the relationships between each Job 
and its required resources are quite simple. Each Job requires a 
fixed number of resource units of one or more types. A pool exists 
for eaOh type. A Job may be scheduled if the pools contain the 
required number of resource units for the duration of the job. An 
illustration of a feasible project schedule is shown in Fig. 3. 4. 3-1 
for two resource types and three Jobs. 


Units of 
Resource 1 





Maximum Allowable Number of 
Resource Units 

JOB Requires 

A 1 Unit Type 1 

2 Units Type 2 
B 1 Unit Type 1 

1 Unit Type 2 
C 3 Units Type 1 

1 Unit Type 2 


fig. Z.4.3-1 Feasible Project Scheduling Example 


Notice that if the total number of resources had not been con- 
strained, all three jobs could have been scheduled concurrently 
producing a shorter schedule. Thus adding resource constraints to 
the problem model usually does alter the CPM (i.e., simple network 
with job durations) schedule. 
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Fig. 3. 4. 3-2 



Fig. 3. 4. 3-2 

Assooiation of Requirements for Footed Resources with Network Jobs 


It is obvious that the problem model for simple project 
scheduling utilizes pooled resources and that each job selects 
indisaz^irnii^tety from the pools and vetume vesoupaes to the 
poots upon oomplet'ion. A job utilizes prescribed quantities 
from the pools. From the resource point of view, the job creates 
an assignment interval during which these qxjantities are de- 
scribed as '*in process” until the job is completed, at which 
time they are described as "available." The descriptors "in 
process" and "available" are called implicit descriptors because 
they can be inferred from the existence of an assignment inter- 
val; i.e., if we know that Job A uses three units of Resource 1 
and Job A is scheduled, then we know implicitly that three units 
of Resource 1 have the descriptor "in process" during the dura- 
tion of Job A. The resources used in the project scheduling 
problem model cany there f ore y be described as pooled resources 
with ^implicit descriptors only. Although this description appears 
at this point to be a terminology overkill, it will be useful 
later in distinguishing the project scheduling model from more 
generalized models . 
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3.4.4 Events in Job Networks 


It is useful to be able to place events into a network in ad- 
dition to jobs. An event may he thought of as a zero duration 
joh that requires no resources. This function is illustrated in 
Fig. 3.4. 4-1. Its basic usefulness is to permit the integration 
of two or more networks. A large network may be decomposed into 
smaller networks- by defining the interfacing events between the 
smaller networks. This may permit network analysis to be accom- 
plished on networks that are too large to be analyzed without 
decompo sit ion . 

The PLANS module library contains several routines that per- 
form operations on generalized networks. The PR0JECT_DEC0MP0SER 
identifies networks within larger networks so that analyses can 
be performed Independently on the smaller networks. The NETWORK^ 
CONDENSER module eliminates the jobs in a network leaving only 
the events. The branches in such an event node network represent 
delay times. The condensation of a network permits a CPM analysis 
on a very large network using decomposition principles. The 

PREDECESSOR_$ET INVERTER module converts all predecessors in a 

network into equivalent successor sets. This inversion is nec- 
essary for performing a CPM analysis (the CRIT ICAL_PATH_PROCESSOR 
and CRITICAL^PATH_CALCULATOR modules are applicable) or for con- 
densing a network into an event node network. 

The permissibility of events in networks allows the problem 
analyst to describe complex networks in terms of subnetworks with 
Interfacing events. A subnetwork is itself a network, which 
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Fig. Z.4.4-1 







contains the djnmedlate predecessors and successors of all its 
member jobs or events that are not Interfacing events. Because 
any subnetwork may, Itself, have one or more Interfacing events 
to still other subnetworks, a helrarchical relationship between 
networks can be described. Scheduling with resource constraints 
may require a single master network. This capability is provided 
in the library by the NETWORK__ASSEHBLER routine. 
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3.4.5 Job Splittability 





3.4.5 Job Splittability 

The simple network can be generalized slightly by permitting- 
spti-ttahle jobs as illustrated in Fig, 3.4, 5-1. Splittable jobs 
are jobs that can be terminated before completion and restarted 
from the interrupt point at any later time. The sum of the dura- 
tions of the job segments is equal to the duration of the original 
job. The HEURISTIC_SCHEDUL ING_PR0CESS0R module and the three 
modules it calls, all permit the description of jobs that are 
splittable or nonsplittable. 
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Start 

Refurbish 
Launch Pad 


Mate Orblter to 
External Tank 


} 


Finish 

Refurbish 
Launch Pad 




Fig. Z, 4.5-1 Illustifation of a Splittdble Job 
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SPECTRUM OF PROBLEM DESCRIPTION GENERALITY 



RESOURCES AND THEIR RELATIONSHIPS TO JOBS 


3*4.6 Variable Resource Requirements 

A simple generalization of the problem model is possible while 
maintaining compatibility with the project scheduling module called 
the HEURISTIC_SCHEDULIN6_PR0CESS0R- This generalization permits 
piecewise constant resource profiles such as that shown in Fig. 

3.4. 6-1. 

The PLANS library modules that have been specified for solv- 
ing project scheduling problems are all capable of handling piece- 
wise constant resource profiles associated with any job. When 
many resource pools are included in the problem model and when 
these resources are shared between many jobs, the resolution of 
resource conflicts becomes a significant problem. This can be 
appreciated by examining Fig. 3. 4. 6-2, which illustrates only 
two resources associated with three jobs. The modules specified 
for the PLANS library will satisfy the complex resource constraints 
associated with a large number of resources and jobs. The 
HEURISTIC_SCHEDULING_PROCESSOR serves as the executive module, 
which calls the NETWORK_ASSEMBLER , the RES0URCE_ALL0CAT0R, and 
the RESOURCE LEVELER modules. See Section 3.6. 

Just as the resource requirements for a single job may be 
variable, so can the total resource pool levels be variable with 
time. Figure 3. 4. 6-3 illustrates a profile that reflects the 
fact that fluctuations will occur in available manpower. 
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Fig, 3. 4. 6-1 Variable -Level Resouroe Requirements 



Manpower 




3.4.7 Item -Specific Resources 



3.4.7 Item-Specific Resources 





3.4.7 Item-Specific Resources 

Many scheduling problems cannot be adequately formulated using 
resource pools. This usually results from the necessity to keep 
track of the assignments for specific resource items. For ex- 
ample, it might not be acceptable to produce a schedule that pro- 
vided only the information that one truck (from a pool) was used 
from 9:00 am to 9:12 am. It is only acceptable to specify that 
truck number 90526 was used. When specific traceable assignments 
are required, the problem model must Include "item-specific re- 
sources." Some item-specific resources that might be required 
by the jobs in the illustration used in previous sections are 
shown in Fig. 3.4.7— 1. The inclusion of item— specif ic resources 
in the operations model permits resource allocation to be coupled 
into scheduling. Problems using item-specific resources are those 
that require the determination of not only when a job is to be 
done and how many resources are to be used, but also which re- 
sources are to be used. Table 3. 4. 7-1 provides several examples 
of pooled and item-specific resources. Because the use of item- 
specific resource descriptions adds to the complexity of the prob- 
lem model, solutions require more sophisticated techniques that 
are much more costly to execute. In addition, tracking all item- 
specific resources adds substantially to computer storage re- 
quirements. Thus, the use of item-specific resources should not 
be done unnecessarily. 
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Perform 

Payload 

Operations 


Perform 

Crew 

Training 


1 5 Specific] 


Begin 

Operations 

Cycle 


Mate 
External 
Tank to 
SRBs 


Mate ^ 
Orb iter to 
External 
Tank j 


Orbit er 

I 

External 
Tank 1 


Launch 


Item-Specific Resources 


Crewmen 

Jones 

Cardwell 

Adams 

Black 


Orbiters 

//A04 

#A07 


External Tanks 
//T106 
#T217 


Refurbish 

Launch 

Pad 


Indicates Partial 
Resource Requirements 
for Job 


7i.g, Z, 4,7-1 IltustvcLtion of Item-Speoifio Resoui'aes Required hy Jobs 


Table 3,4. 7-1 
Examples of Pooled and 
Item-Specific Resources 


Pool 

Item-Specific 

Crewmen 

Jones 

Clayborn 

Betts 

Blackburn 

Vehicle Seating 
Units 

Bus 6 

Shuttlebus 

Van 

Food Units 

Meal 6 
Supplement 2 
Meal 4 

Computer Storage 
Cells 

Disc, 2 
Tape 6 

Core Block 2 

Machines 

Lathe 1 
Auto Lathe 
Lathe 6 
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3.4.8 Resource Alternatives 


Many problems require the consideration of alternative (sub- 
stitutable) resources, as illustrated in Fig. 3.4. 8-1. These 
alternatives may be directly substitutable (i.e., an adjustable 
wrench may be substituted for an open-end wrench) or only func- 
tionally comparable (i.e., a conveyer may be functionally equiva- 
lent to three laborers). The . selection between alternatives may 
be based on a preset priority with the availability of the re- 
source as the criterion. Other alternatives may influence some 
problem "figure of merit" such as duration, total cost, or re- 
source utilization smoothness. In this case, an executive logic 
could be empowered to evaluate the effects of its selections. 
Typically a heuristic decision rule must be used to make the 
selections between resource alternatives during the algorithm 
operations. 

Within the operations model, the required resources are de- 
fined in the definition of a process as a series of "and" and "or" 
resources. That is, a process requires each of the resources of 
the "and" portion plus one of the alternatives of each partition 
of the "or" section of the process definition.. This approach 
readily identifies those resources in a process definition that 
have suitable alternatives. 
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Fig, 3. 4. 8-1 



3.4.9 Process Alternatives 
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3.4.9 Process Alternatives 

Process alternatives such as the one shown in Figure 3.4. 9-2 
may arise in a problem description as a means of handling resource 
alternatives or because a processing option must be modeled. A 
conversion from resource alternatives to process alternatives 
results if each combination of resource alternatives is consid- 
ered as a distinct process. (See Fig. 3. 4. 9-1.) 



RESOURCE PROCESS 

ALTERNATIVE ALTERNATIVE 

Fig. 3. 4. 9-1 

Conversion from Resource Alternatives 
to Process Alternatives 

This approach becomes very cumbersome if many of the resources 
required for a process have alternatives because each .combination 
of resource alternatives implies a unique process definition. A 
substitutable process is created either by alternative resource 
combinations or by the existence of functionally equivalent and 
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Fig, 5. 4. 9-2 Illustration of Process Alternatives 


and redundant activities (i.e., any number of the required re- 
sources may be different) , In network form, these process alter- 
natives can be shown as in sketch A where process B and C represent 



the alternatives. Similarly, alternative subnetworks can be spec- 
ified if more than one process is involved in the alternative 
subnetworks. For example, the subnetworks B and C, as shown in 
sketch B, would define alternative subnetworks. 



In subsequent discussions of the operation model, networks 
and subnetworks are referred to as operations sequences, because 
the latter term is more descriptive of the temporal relations 
between processes. 

At this point it may be necessary to make a distinction be- 
tween alternative operations sequences and conditional branches 
in formulating his solution strategy. For this purpose, consider 
the "alternative operations sequences" as functionally equivalent 
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subnetworks for which the selection criterion is based on a prob- 


lem objective such as least -cost, minimum time, resource avail- 
ability, etc. This decision would, therefore, have to depend on 
the contents of the subject subnetworks and a prediction or simu- 
lation of the impact of choosing each alternative. In contrast, 
consider a "conditional branch" as a switch between separate sub- 
networks, which may or may not be functionally the result of ac- 
tivities completed earlier in the network. This selection would 
be independent of the overall problem objective function and, 
therefore, independent of the contents of the subnetworks. 

To illustrate this distinction, consider a machining activity 
In which a part may be produced by either mechanical milling or 
chemical milling. Each method could be modeled as a subnetwork 
in a larger shop model. Because the beginning and end states of 
the particular part are identical, the selection of method to be 

IK 

used Could be based on comparative cost or duration, or possibly 
some other problem constraint such as least manpower required. 
Thus, these functionally equivalent subnetworks would be "alter- 
native operations sequences." Conversely, a Shuttle operations 
model might contain two or more subnetworks that define checkout 
sequences for payloads. The selection criterion in this case 
would depend on the characteristics of the payload under consid- 
eration. Because the particular payload would be selected earlier 
in the operations "loop", the "conditional branch" selection 
would not be based on an objective function of the problem or 
contents of the subnetworks, but on operational constraints* 


110 



3,4.10 General Temporal 
Relations 




3.4.10 General Temporal Relations 





3.4.10 General Temporal Relations 

Occasionally, the sequences between processes must be described 
with relationships that are more general than the simple prede- 
cessor relationship (If the end of activity A must occur before 
the beginning of activity B, then A is simply a predecessor of B.) 
In a more general operations model, however, other temporal re- 
lationships may exist such as the one illustrated in Fig. 3.4.10-1. 

If a set of "alternative operations sequences" exists in a 
network (as shown in the sketch) , it would be incongruous to spec- 
ify both alternatives as predecessors to the subsequent activity 
(D) because both predecessors cannot be completed. However, it 
is necessary to indicate the direction of flow regardless of the ■ 
alternative selected. In this case, unambiguous specification 
would label the subsequent activity (D) as a "successor" to both 
alternatives. 



Temporal relations that are more general than either prede- 
cessors or successors may be represented as 



where i and j are any activities or events in the project and "s" 
denotes a start time while "f" signifies a finish time. The 
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Fig, Z, 4, 10-1 Ittustjyation of a General Temporal Relations 


addition of fixed time intervals (K) or inequalities containing 
constant time intervals has many applications in system modeling. 
For example, a system Involving the pouring of concrete may have 
a constraint specifying that the troweling activity must begin 
within 30 minutes of completion of the pouring. Similarly, an 
activity involving a sealing coat may be constrained not to start 
within 48 hours of completion of the pouring activity. The PLANS 
module library contains three modules that can be used with gen- 
eral temporal relationships. These are CHECK_EXTERNAL_TEMP_ 
RELATIONS, CHECK_INTERNALJ‘EMP_RELATIONS, and CHECK_ELEMENTARY_ 
TEMP^RELATION . All perform checking for constraint satisfaction. 

Our approach to handling the generalized temporal relation- 
ships is to reduce the network to closely continuous and ordinary 
predecessors or successors by introducing "dummy" activities. 

Dummy activities have finite durations, but differ from regular 
activities in that no resources may be required. Thus, they rep- 
resent a span of time in a network or subnetwork, ’Closely con- 
tinuous’ implies that the end time of a preceding activity equals . 
the start time of the successor activity. Although methods exist 
for handling general temporal relationships, they are substantially 
more complex than methods that handle only predecessors and suc- 
cessors. The modeler is, therefore, encouraged to use general 
temporal relationships only when simple predecessor/successor 
relationships have proven Inadequate. 
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RESOURCES AND THEIR RELATIONSHIPS TO JOBS 


3.4.11 Item-Specific Resources with Explicit Descriptors 


Processes require many resources that change their previous 
characteristics and thus must have additional explicit descriptors. 
For example, in Fig, 3.4.11-1, the job "Mate Orbiter to External 
Tank" is shown to require one orbiter with a status descriptor 
REFURBISHED. It is a property of explicit ' descriptors that they 
change only at the end of the process time and that the way they 
change must be specified explicitly as a part of the process def- 
inition. For example, if a given resource. Truck 87, had been 
assigned to two activities that first loaded the truck and then 
drove it to Los Angeles, it might have a descriptor LOAD STATUS 
with a corresponding value LOADED, and a descriptor LOCATION with 
a value LOS_ANGELE$. These data would be retained as part of 
the two assignments for the resource. If a subsequent activity 
moved the truck to San Francisco, the result would be to change 
the descriptor LOCATION. The descriptor LOAD STATUS would be 
unaffected by the current process and any inquiry concerning 
Truck 87 at a subsequent time would find the loaded truck in San 
Francisco. (Because the driver is considered a separate resource, 
it should not be inferred that the driver was found loaded in 
San Francisco!) 

It should be noted that explicit descriptors must have mutually 
exclusive values for any given descriptor. That is, if, in the 
example just discussed, the truck were moved to DOCK 23, an ad- 
ditional descriptor (i.e., D0CK_L0CATI0N) should be added if the 
location SAN_FRANC ISCO were to be retained. 
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Fig. 3.4.11-1 



Fig. 3.4.11-1 IVluatTotion of an Item-Speoifio Resoiaaoe with an. Explicit Descy*Cptor 


It should also be noted that if activities are being placed 
on a timeline ahead of some previously scheduled activities (time- 
transcendant scheduling), the resource profile for all times later 
than the new activity may be altered. The module library contains 
a routine called CHECK_DESCRIPTOR_COMPAT IBIL IT Y , which determines 
conflicts that would result in attempting to schedule a job re- 
quiring an item-specific resource with explicit descriptors. 
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RESOURCES AND THEIR RELATIONSHIPS TO JOBS 


3.4.12 Pooled Resources with Explicit Descriptors 

Pooled resources represent a very difficult extension of the 
generalization capability of explicit descriptors. Because ex- 
pile it descriptors alter a resource so that it does not revert 
to its original state at the end of the scheduled activity, a 
pool is continually repartitioned as resources are allocated to 
various activities. This repartitioning is illustrated in Fig. 
3.4.12-1. Since it is necessary to know from which partition a 
set of resources is to be drawn, it becomes necessary to describe 
the partitionings of the entire pool for each assignment made. 

This obviously becomes very cumbersome as the size of the pool 
or the number of assignments grows. The problem is compounded 
’ if time -transcendent scheduling is attempted or if activities 
previously scheduled must be unscheduled. The module POOLED^ 
DESCRIPTOR_COMPATIBILITY is designed to identify the descriptor 
conflicts that occur when attempting to insert a job on the time- 
line that requires pooled resources with explicit descriptors. 

When unscheduling, pooled resources for all activities occurring 
at a later time must be repartitioned to reflect the unscheduled 
resources. 

Both of these techniques become extremely cumbersome and time- 
consuming as the size of the problem increases. If the explicit 
descriptors required to describe a given resource can be antic- 
ipated and the number of such descriptors is small, the various 
partitions of the pooled resource can, themselves, be considered 
a pooled resource. In this case, the pooled resource can be 
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Fig. 3.4.12-1 




Created as if it had only the implicit descriptors of IN PROCESS 
or AVAILABLE, thereby avoiding the complexity of modeling using 
pooled resources with explicit descriptors* Although data struc- 
tures, conventions, and library modules are provided for schedul- 
ing that accommodate the most complex problem models, it is rec- 
ommended that substantial effort be devoted to analyzing modeling 
alternatives that will permit greater use of well-developed tech- 
nology and substantially less demanding logic design and checkout 
efforts. Alternatives include the definition of separate pools 
without explicit descriptors for each anticipated partition, and 
the substitution of item-specific resources with explicit des- 
criptors for elements of the pool. 
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3,5 


OPERATIONS MODEL DATA STRUCTURES 


This report has discussed the basic data structure of PLANS 
and presented the rationale for assuming a general hierarchical 
form. It should be noted that any "standardized” modules must 
make some assumptions as to the location of particular data within 
the overall structure. Therefore, this section defines some 
standard data trees for modeling an operational system. The trees 
discussed are summarized in Table 3.5-1, These standardized trees 
are an Important part of the Operations Model, which is used as 
a framework for the library modules specified in Volume III. Ob- 
viously, these structures may be augmented to accommodate partic- 
ular program peculiarities as the programmer deems necessary, or 
may be disregarded completely if no modules are used that assume 
the standardized structures. It should be recognized that the 
trees are defined from a "modeling” viewpoint and that few, if 
any, modules will use the entire content of any given tree. The 
"mandatory" contents assumed by each module for any given tree 
structure are defined in the functional specification of that 
module. No modules have been specified for the library that 
recognize the absence of required data and initiate logic to sup- 
ply the missing data. PLANS coding can be used to build such 
routines, however. For example, logic that reads a node called 
DURATION and, finding no numeric value, calls a routine whose 
name appears as the value is easily written in PLANS. Neverthe- 
less, no PLANS library modules contain such logic. Therefore, 
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it is the programmer /user ’ s responsibility to ensure that required 
data are supplied to a called library module. In general, the 
order of nodes at a given level is insignificant. 


Table 3.5-2 Operations Model Data Structures 


The problem descriptions of Section 3.4 can be represented as 
hierarchical data trees compatible with the PLANS language. 

User-Defined Data Trees are 

$RES0UPXE 

Describes the resources of the system 
(3.5.i) 

$PR0CESS 

Describes Che activities of the system 
(3.5.2) 

$0PSEQ 

Describes the operational sequences of 
the system (3.5.3) 

$OBJECTIVES 

Describes the objectives and constraints 
of a problem 

The problem descriptions of Section 3.4 can be used in PLANS 
programs to generate schedules and/or resource allocations. 
The information associated with problem solutions can also be 
represented in hierarchical data trees compatible with the 
PLANS language. 

Program-Created Data 

Trees are 

$J0BSET 

Describes each single occurrence of a 
process of a problem (3.5.5) 

$SCHEDULE 

Describes each job and the associated 
resources that are assigned to a spe- 
cific time interval (3.5.6) 

ASSIGNMENT Subnode 
of $RES0URCE 

Describes the assignments made for each 
resource of a problem (3.5.7) 


The Operations Model, standard data trees can be classified 


either as user-defined or as program-created as shown in Table 
3.5-1. User-defined data trees are structures built by a user to 
describe the system of interest. They provide the mechanism by 
which the user provides data to the program. Program-created 
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data trees are generated during the execution of the scheduling 
logic. These fundamental structures are created or used by many 
of the library modules. Therefore, they serve to integrate the 
modules and should form a basis for specific program executive 
logic. 


e> 
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3.5.1 $RESOURCE 




OPERATIONS MODEL DATA STRUCTURES 


The problem descriptions of Section 3.4 can be represented as 
hierarchical data trees compatible with the PLANS language. 

THE USER-DEFINED DATA TREES ARE: 


■ 

$RES0URCE 

Describes the resources of 
the system 

$PR0CESS 

Describes the activities 


of the system 

$0PSEQ 

Describes the operational 


sequences of the system 

SOBJECTIVES 

Describes the objectives 


and constraints of a problem 

The problem descriptions of Section 3.4 can be utilized in PLANS 
programs to generate schedules and/or resource allocations. The 
information associated with problem solutions can also be repre- 
sented in hierarchical data trees compatible with the PLANS lan- 
guage . 

THE PROGRAM-CREATED DATA TREES ARE: 

$J0BSET Describes each single occur- 

rence of a process of a 
problem 

$SCHEDULE Describes each job and the 

associated resources that 

ASSIGNMENT subnode 
of $RES0URCE 

a problem 


are assigned to a specific 
time interval 
Describes the assignments 
made for each resource of 



3.5.1 $RESOURCE 


$RESOURCE provides the structure to define all supplies, ele- 
ments, or resources needed to perform any activities to be modeled 
in the system of interest. This definition includes the quantity 
and characteristics of the resource as well as a record of allo- 
cations or ASSIGNMENTS made for the given resource. (Because 
the ASSIGNMENTS are not defined by the user but result from ex- 
ecution of the program, this portion of $RES0URCE will be discussed 
in the next section). As illustrated in Fig. 3.5.1— 1, $RES0URCE 
provides two levels of resource classification; these are arbi- 
trarily referred to as TYPE and NAME. These two levels allow 
relatively quick access to a specific resource or a given class 
of resources. The lower level of classification (resource name) 
may define either an item-specific resource or resource pool. 

As discussed previously, it is necessary to distinguish be- 
tween item-specific and pooled resources. Therefore, the next 
sublevel contains a node labeled CLASS with expected values being 
either SPECIFIC or POOL. In addition, this level provides the 
initial time and description of the given resource. This descrip- 
tion has a node for each descriptive parameter required. The 
node label names the parameter and the node value gives the cor- 
responding parametric value. Thus, descriptive characteristics 
such as length, weight, color, location, etc that apply to the 
resource at the initial time may be specified. 
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Initial quantities for pooled resources may be time-varying. 
To accommodate this possibility, a node labeled IN IT IAL_PROFILE 
appears in $RES0URCE, The substructure under this node provides 
the mechanism for defining variable piecewise constant profiles 
for both normal and contingency quantity levels. The profile 
data are typically used with project scheduling techniques. It 
should be stressed that all the values under the IN ITIAL_PROF ILE 
node and the other nodes at that level represent initial values. 
Any subsequent changes to the descriptive characteristics re- 
sulting from assignments to specific processes would be recorded 
in the assignment portion of $RES0URCE. See Section 3.5.6. 

An illustration of the use of $RES0URCE for a Shuttle appli- 
cation is shown in Fig. 3. 5. 1-2. 
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SRESOURCE 

SRB 

SRB 

QUANTITY - 18 
CLASS - POOL 

VA6 HIGH BAY 
HIGH BAY NO. 1 
QUANTITY - 1 
LOCATION - BAY 1 
CLASS - SPECIFIC 

HIGH BAY NO. 2 
QUANTITY -1 
LOCATION - BAY 2 
CLASS - SPECIFIC 

PERSONNEL 

SRB/EXT. TANK CREW 
QUANTITY - 55 

QUALIFICATIONS - ASSEMBLE 5RBS 

- PREPARE EXT. TANKS 

- MATE TANK AND SRB 

- REFURBISH LUT 

CLASS - POOL 

LAUNCH CREW 
QUANTITY - 75 

QUALIFICATIONS - SERVICE SHUTTLE 

- LAUNCH OPS 

- REFURBISH PAD 

CLASS - POOL 

ORB I TER/PAYLOAD CREW 
QUANTITY - 45 

QUALIFICATIONS - PERFORM PAYLOAD OPS 
“ PREPARE OR0ITER 

- RECYCLE ORBITER 

- MATE ORBITER AND TANK 

CLASS - POOL 
ASSIGNMENT - 
MISSION CONTROL 
QUANTITY - 65 

QUALIFICATIONS - ON-ORBIT OPS 

- OEORBIT AND LAND 

CLASS - POOL 

CREW OPS 

QUANTITY - 75 

QUALIFICATIONS - CREW TRAINING 

- MISSION BRIEFING 

- FLIGHT CREW PREP 

- DEBRIEFING 

CLASS - POOL 

LAUNCH UMBILICAL TOWER 
LUT 

QUANTITY - 3 
CLASS - SPECIFIC 

EXT, TANK 
EXT. TANK 

QUANTITY - 7 
CLASS - POOL 

ORBITER 

ORBITER 

QUANTITY -3 
CLASS - SPECIFIC 

LAUNCH PAD 

LAUNCH PAD NO. 1 
QUANTITY - 1 
LOCATION - PAD 1 
CLASS - SPECIFIC 

LAUNCH PAD NO. 2 
QUANTITY - 1 
LOCATION - PAD 2 
CLASS - SPECIFIC 


CREW 

CREW 

QUANTITY -15 
CLASS - POOL 

PAYLOAD 

PAYLOAD 

QUANTITY - 163 

Fig, d, 5.1-2 
^RESOURCE Data Tree for 
a Shuttle Application 
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3.5.2 $PROCESS 




OPERATIONS MODEL DATA STRUCTURES 

The problem descriptions of Section 3.4 can be represented as 
hierarchical data trees compatible with the PLANS language. 

THE USER-DEFINED DATA TREES ARE: 


$RES0URCE 

Describes the resources of 


the system 

$PR0CESS 

Describes the activities 


of the system 

$0PSEQ 

Describes the operational 

$OBJECTIVES 

sequences of the system 
Describes the objectives 


and constraints of a problem 

The problem descriptions of Section 3.4 can be utilized in PLANS 
programs to generate schedules and/or resource allocations. The 
information associated with problem solutions can also be repre- 
sented in hierarchical data trees compatible with the PLANS lan- 
guage . 

THE PROGRAM-CREATED DATA TREES ARE: 

$J0B5ET Describes each single occur- 

rence of a process of a 
problem 

^SCHEDULE Describes each job and the 

associated resources that 
are assigned to a specific 
time interval 
Describes the assignments 
made for each resource of 


ASSIGNMENT subnode 
of $RES0URCE 


a problem 




3.5.2 $PROCESS 


This data structure defines the activities or processes of 
the system to be modeled. Obviously, the level of detail to be 
included determines the content of the $PR0CESS tree. For ex- 
ample, a top-level analysis of a system may group many activities 
into one process with a corresponding total duration. In such 
instances some or all of the resources involved in the activities 
may not be specified. In contrast, the problem objective may 
require such detail as the skill profile of each person who is 
considered a resource, and/or variable use of resources during 
the process time interval. The structure of $PR0CESS, as shown 
in Fig. 3. 5. 2-1, allows both extremes to be modeled. Again it 
should be emphasized that only applicable portions of the struc- 
ture need to be specified. Thus, conceivably, a process defini- 
tion could consist of as little as the process name and a cor- 
responding duration. 

The first level subnodes to the process name define the proc- 
ess duration and type. In this usage, type refers to whether or 
not a process may be split into segments to facilitate scheduling 
around constraints. Expected values would be either SPLITTABLE 
or NOT_SPLITTABLE . A programmer may wish to provide a default 
value for type to permit simplification of program input, but 
the functional specifications for library modules leave all de- 
fault nodes to the discretion of the implementer. This level also 
labels the nodes needed to define the relationship of resources 
to the process being defined. 
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The substructure of REQU IRED_RESOURCES contains the most spe- 
cific information required to ensure a satisfactory resource se- 
lection for the process. Thus, if any resource of a given type 
(first sublevel to REQUIREO_RESOURCE) will suffice, only the 
resource type is defined. (The name level is left null.) Con- 
versely, a process may require a resource of a given type and 
ruxmey and in addition require a particular value of a given 
deseniptov at the initiation of the process. In this instance, 
an INITIAL_DESCRIPTOR would be specified for the given resource. 

As Illustrated in the structural diagram of $PR0CESS, any number 
of resource types and/or names may be required by a given process. 
It is assumed that each resource denoted by a node at the name 
level is required to complete the process. For each resource 
name (indicated by a node) , any number of descriptors may be spec- 
ified for a given time interval. It is assumed that any initial 
descriptor defines a requirement on the resource that must be 
met for a resource to be an acceptable candidate. A FINAL_DES- 
CRIPTOR only indicates a change in a particular descriptor re- 
sulting from the accomplishment of a process. The START and END 
values specified for a given INTERVAL will define an interval 
relative to the process duration. Thus, if the value of DURATION 
is 10, a START and END value of 5 and 10, respectively, would 

t 

indicate that the resource was only required for the last half 
of the process. 
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Processes are the mechanism for associating resources with 
activities. For this reason, multiple requirements for resources 
defined within a single process will be satisfied by a collection 
of resources and the assignments of each resource will be identi- 
fied by the process name but not by a separate requirements iden- 
tifier. For example, a single process that has a requirement for 
one crewman and another requirement for a different crewman will 
ultimately cause two crewmen to have assignments identified by 
the process name. It is assumed that the association of each 
crewman with a particular requirement will not be preserved. If 
the association is to be preserved, two separate processes should 
be defined. In the Operations Model, a process contains a set 
of requirements to which resources can be assigned unambiguously. 

The format of the data structures subordinate to ALTERNATE^ 
RESOURCES, RESOURCES_GENERATED, and RESOURCES_DELETED is similar 
to that for REQU IRED_RESOURCES , but functionally, each serves a 
different purpose. ALTERNATE_RESOURCES defines any number of 
sets of alternative resources. Each set is represented with a 
null label (shown as "c" in Fig. 3. 5. 2-1). It is assumed that 
one alternative from each set must be provided for completion of 
a given process. Thus, an executive program must consider both 
nodes, REQUIRED^RESOURCES and ALTERNATE^RESOURCES, when determin- 
ing the availability of resources required to complete a process. 

RESOURCES_GENERATED and RESOURCES_DELETED specify what happens 
to resources during a process. In some cases resources will be as- 
sembled (or disassembled) to create new resources. Correspondingly, 
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the initial elements will no longer exist as the described re“ 
source. For example, if a process mates an Orbiter to a stack, 
the resulting assembly may be referred to as a Shuttle. In this 
case, the resource Orbiter and stack would be described as 
RESOURCES_DELETED and the resource Shuttle would be a RESOURCE^ 
GENERATED. These nodes, therefore, allow a means of traceability 
for a particular resource. These two substructures also describe 
resources that are usually thought of as "expendables” or "con- 
sumables”. A resource, such as power, dollars, or fuel, that is 
in fact consumed and will not reappear in the system at a later 
time, would be a deleted resource. Similarly, a "negative” con- 
sumable, such as the refining of a petroleum product, would create 
resources during a process. An illustration of a portion of 
$PR0CESS for a Shuttle application is shown in Fig-. 3.5. 2-2. 
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SPROCESS 

RECYCLE SRB 
OURATION - 11 
REQUIRED RESOURCES 
SRB 

SRB 

t 

INTERVAL 
START - 0 
END - 11 
DESCRIPTORS 

INITIAL 

QUANTITY - 2 
STATUS - TO BE RECOVERED 
FINAL 

QUANTITY - Z 

STATUS - TO BE ASSEMBLED 

ASSEMBLE SRB PAIR 
DURATION * 0.4 
REQUIRED RESOURCES 
SRB 

SRB 

i 

INTERVAL 
START - 0 
END - 47 
DESCRIPTORS 
4 

INITIAL 

QUANTITY - 2 
STATUS - TO BE ASSEMBLED 
FINAL 

STATUS - TO BE MATED 

VAB HIGH BAY 
VAB 

t 

INTERVAL 
START - 0 
END - 47 
DESCRIPTORS 
4 

INITIAL 

STATUS - AVAILABLE 
FINAL 

status - IN USE 

PERSONNEL 

SRB/EXT TANK CREW 
4 

INTERVAL 
START - 0 
END - 47 
DESCRIPTORS 
4 

INITIAL 

QUANTITY - 30 

QUALIFICATIONS - ASSEMBLE SRBS 
LAUNCH UMBILICAL TOWER 
LUT 

4 

INTERVAL 
START - 0 
END - 47 
DESCRIPTORS 
4 

INITIAL 

QUANTITY - 1 
STATUS - AVAILABLE 
FINAL 

STATUS - IN USE 
RESOURCES GENERATED 
SRB PAIR 
SRB PAIR 
4 

DESCRIPTORS 

4 

FINAL 

QUANTITY - 1 

RESOURCES DELETED 
SRB 

SRB 

4 

DESCRIPTORS 

4 

INITIAL 

QUANTITY - 2 
FINAL 

QUANTITY - 0 

Firg. 3,5. 2-2 

Use of $ PROCESS for a Shuttle 
Application 


136 




3.5.3 $OPSEQ 



OPERATIONS MODEL DATA STRUCTURES 


The problem descriptions of Section 3.4 can be represented as 
hierarchical data trees compatible with the PLANS language. 

THE USER-DEFINED DATA TREES ARE: 

$RES0URCE Describes the resources of 

the system 

$PR0CE$S Describes the activities 

of the system 

$0PSEQ Describes the operational 

sequences of the system 
^OBJECTIVES Describes the objectives 

and constraints of a problem 

The problem descriptions of Section 3.4 can be utilized in PLANS 
programs to generate schedules and/or resource allocations. The 
Information associated with problem solutions can also be repre- 
sented in hierarchical data trees compatible with the PLANS lan- 
guage. 

THE PROGRAII-CREATED DATA TREES ARE :• 

,$J0BSET Describes each single occur- 

rence of a process of a 
problem 

$SCHEDULE Describes each job and the 

associated resources that 
are assigned to a specific 
time interval 

ASSIGNMENT subnode Describes the assignments 

of $RES0URCE made for each resource of 

a problem 




3.5.3 $OPSEQ 


The operations sequence data structure serves to define the 
relationship between processes that are combined into a network. 

As illustrated in Fig. 3. 5. 3-1, the labels of the first level 
subnodes are the names of different operations sequences. The 
labels of the second-level subnodes are the names of the elements 
of the above-named operations sequence. The element is either 
a process or another operations sequence; if it is an operations 
sequence, its name will also appear elsewhere at the first level 
to define its substructure. If the element is a process, its 
characteristics are described by the $PR0CESS tree. The element 
TYPE is defined by the next level subnode with an expected value 
of either PROCESS or OPSEQ. The module CHECK_PROCESS_DEFINITION 
provides a capability to check whether all processes referred to 
in the nested operations sequences are defined in $PR0CESS. 

This level also defines the general temporal relationship of 
an element to any other element in the same operations sequence. 
This data structure (see Fig. 3.5. 3-2) allows the user to specify 
classical predecessors and successors as well as generalized tem- 
poral relations. The general temporal relation is specified by 
six order-ed subnodes as indicated in Fig. 3. 5. 3-2. (It is pos- 
sible that appropriate labels could be designated, and interpreted, 
to eliminate the requirement to be ordered, but since the order 
is logical and unambiguous, the labels have not been assumed by 
any library modules.) 
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Fig. 3. 5.3-2 $OPSEQ Standard Data Structure 


L38 





Fig. 3. 5, 3-2 General Substructure for TEMPORAL RELATIONS 



Finally, any alternatives to an element may be listed as 
values of subnodes to ALTERNATIVES. Alternatives represent OR 
gates in an operations sequence. As discussed in the previous 
section, these alternatives may be either processes or operations 
sequences. 

An illustration of the use of $0PSEQ for a Shuttle application 
is shown in Fig, 3. 5. 3-3. 
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50PSEQ 

SHUTTLE SYSTEM MISSION FLOW 
ASSEMBLE SRB PAIR 
TYPE - PROCESS 
PREPARE EXT. TANK 
TYPE - PROCESS 
MATE EXT. TANK TO SRB 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

ASSEMBLE SRB PAIR 
PREPARE EXT. TANK 
MATE ORB I TER TO EXT. TANK 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

MATE EXT. TANK TO SRB 
PREPARE ORB I TER FOR LAUNCH 
SERVICE SHUTTLE FOR LAUNCH 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

MATE ORB I TER TO EXT. TANK & SRB 
LAUNCH PHASE OPERATIONS 
TYPE - PROCESS 
TEMPORAL RELATIONS 
GENERAL 
C 

START 

EQUAL TO 

END 

SERVICE SHUTTLE FOR LAUNCH 
PREDECESSOR 

PREPARE CREW FOR FLIGHT 
PREPARE CREW FOR FLIGHT 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

PERFORM MISSION BRIEFING 
GENERAL 
i 

END 

EQUAL TO 

END 

SERVICE SHUTTLE FOR LAUNCH 
REFURBISH LAUNCH PAD 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

LAUNCH PHASE OPERATIONS 
RECYCLE SRB 

TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

LAUNCH PHASE OPERATIONS 
PERFORM ON-ORBIT OPERATIONS 
TYPE - PROCESS 
temporal RELATIONS 
PREDECESSOR 

launch PHASE OPERATIONS 
OEORBIT, REENTRY AND LAND 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

OEORBIT, REENTRY AND LAND 
RECYCLE ORB I TER 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

DEORBIT, REENTRY AND LAND 
PERFORM CREW TRAINING OPS 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

PERFORM PAYLOAD OPS 
PERFORM MISSION BRIEFING 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

PERFORM CREW TRAINING OPS 
perform PAYLOAD OPS 
TYPE - PROCESS 
PREPARE ORBITER FOR LAUNCH 
TYPE - PROCESS 
TEMPORAL RELATIONS 
PREDECESSOR 

PERFORM PAYLOAD OPS 


Fig. 2. 5,3-5 

Use of $OPSEQ for a 

Shuttte Application 
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3.5.4 $OBJECTIVES 





OPERATIONS MODEL DATA STRUCTURES 


The problem descriptions of Section 3.4 can be represented as 
hierarchical data trees compatible with the PLANS language. 

THE USER-DEFINED DATA TREES ARE: 


$RES0URCE 

Describes the resources of 


the system 

$PR0CESS 

Describes the activities 


of the system 

$0PSEQ 

Describes the operational 


sequences of the system 

SOBOECTIVES 

Describes the objectives 

- 

and constraints of a problem 


The problem descriptions of Section 3.4 can be utilized in PLANS 
programs to generate schedules and/or resource allocations. The 
information associated with problem solutions can also be repre- 
sented in hierarchical data trees compatible with the PLANS lan- 
guage . 

THE PROGRAM -CREATED DATA TREES ARE: 

$J0BSET Describes each single occur- 

rence of a process of a 
problem 

$SCHEDULE Describes each job and the 

' associated resources that 

are assigned to a specific 
time interval 

ASSIGNMENT sub node Describes the assignments 

of $RES0URCE made for each resource of 

a problem 




3.5.4 $OBJECTIVES 

The three previous data trees provide a method for describing 
an operational system (or any number of systems) . These trees 
may be constructed at any time and stored and are independent of 
the particular problem of interest at any given time. As a mat- 
ter of fact, they are independent of the scheduling function for 
which they will probably be used. However, there also exist cer- 
tain data that are required as input for a particular problem con- 
cerning a given system. These data may be structured in a variety 
of ways, and will contain different information for different 
problems. $OBJECTIVES, as defined here, presents some data needed 
by certain library modules in a structure that may be used and 
augmented by a program developer. As programs are developed in 
PLANS, $OBJECTIVES will certainly evolve beyond those presented 
here with additional conventions and structure. 

As shown in Fig. 3. 5. 4-1, the first level subnodes include 
a method of inputing a problem name. Obviously, other problem 
identifiers may be included by additional nodes. A Figure of 
Merit node is shown to indicate a location for the name input 
for a routine that calculates the objective function of the prob- 
lem. Because none of the specified library modules require these 
particular data, the detailed specification is not provided here- 
Similarly, a CONSTRAINT node is Indicated for probable inclusion 
by a user of $OBJECTIVES. These constraints would apply to the 
overall problem — not to a specific process or operations sequence. 
Constraints could include the earliest and latest start and end 
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Fig, 3, 5. 4-2 


C'PROCESS' 


lOBJECTIVES 



Fig. Z. 5.4-1 ^OBJECTIVES Standocrd Data Structure 






times (absolute times), maximum total duration, and/or specific 
"windows” that may or may not be used for scheduling. For ex- 
ample, a given shop operation to be scheduled may have an earliest 
start date specified because of expected shipping. of supplies. 

Also, all weekend dates may be unavailable for scheduled activities 
because the shop works on a five-day work week. 

The information in $OBJECTIVES that is required by the cur- 
rently-specified library modules is the list of operations se- 
quences to be scheduled and any specific resources to be associated 
with any process or operations sequence. The first level subnodes 
to OPSEQ list the processes and/or operations sequences that must 
be scheduled for successful completion of a problem. The next 
sublevel lists the TYPE (either PROCESS or OPSEQ) and any temporal 
relationships that exist between that element and any other ele- 
ment under OPSEQ. The format of the temporal relationship is the 
same as discussed in the preceding section on $0PSEQ. Obviously, 
one way of setting up a problem would be to create an operations 
sequence in $0PSEQ containing all the elements desired for a given 
problem. Then $OBJECTIVE would only list one operations sequence 
to be considered and the problem input would be greatly simplified. 
In fact this wou]d be a recommended approach if a similar problem 
were to be considered numerous times. However, the basic philosophy 
has been to consider a more flexible approach in which more ele- 
mental subnetworks are created from individual processes. A num- 
ber of these operations sequences could then be called out in 
$OBJECTIVES to synthesize a given problem. The substructure of 
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the ASSOCIATED_RESOURCES is the same as the $PROCESS . (NAME) .REQUIRED_ 
RESOURCES) substructure and is used to specify any specific resources 
the user wants associated with the corresponding operations se- 
quence. It is assumed that the characteristics of the particular 
resource have previously been filed in the $RES0URCE tree. This 
substructure would be used if the user wished to execute an op- 
erations sequence such as LAUNCH PAYLOAD three separate times 
with an associated resource for each launch of PAYLOAD 14, PAYLOAD 
27, and PAYLOAD 87, respectively. 

An example of the use of $OBJECTIVES for a specific problem 
appears in Section 4.2. 
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3.5.5 $JOaSET 

This data tree will be created near the beginning of a prob- 
lem from the three defined data trees $OBJECTIVES, $0PSEQ, 
and $PR0CESS by the module GENERATE_JOBSET (see Volume III). As 
illustrated by Fig. 3.5.5— 1 this tree combines processes with all 
required resources (whether they are specified or generic) into 
jobs. Thus, a job is a single oocurenee of a process and is the 
element of the Operations Model that is scheduled by the solution 
algorithm. Once created, $J0BSET contains most of the input data 
required to work a given problem and makes further reference to 
the stored trees $0PSEQ and $PR0CESS unnecessary. 

The first-level subnodes of $J0BSET represent a collection 
of single occurrences of the processes In an operations sequence. 
The descendants of. these nodes are unique job identifiers. The 
first level subnodes to the job identifiers specify a J0B_TYPE, 
which indicates whether a job may be interrupted and scheduled 
in more than one segment. The JOB_INTERVAL node contains a rela- 
tive interval equal to the duration of the process involved. The 
substructure of RESOURCES will be created for each required re- 
source and the most specific input information. Other informa- 
tion such as identifiers, alternatives, and temporal relation- 
ships to other jobs are also included in $J0BSET. 
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Fig. 3. 5. 6-1 $JOBSET Standard Data Structure 


3,5.5 $JOBSET 




OPERATIONS MODEL DATA STRUCTURES 


The problem descriptions of Section 3.4 can be represented as 
hierarchical data trees compatible with the PLANS language. 

THE USER^DEFINED DATA TREES ARE: 


$RES0URCE 

Describes 

the resources of 


the system 

$PR0CESS 

Describes 

the activities 


of the system 

$0PSEQ 

Describes 

the operational 


sequences 

of the system 

$OBJECTIVES 

Describes 

the objectives 


and constraints of a problem 


The problem descriptions of Section 3.4 can be utilized in PLANS 
programs to generate schedules and/or resource allocations. The 
information associated with problem solutions can also be repre- 
sented in hierarchical data trees compatible with the PLANS lan- 
guage . 


THE PROGRAM-CREATED DATA TREES ARE: 


$00BSET 

Describes each single occur- 
rence of a process of a 


problem 

$SCHEDULE 

Describes each job and the 


associated resources that 


are assigned to a specific 


time interval 

ASSIGNMENT subnode 

Describes the assignments 

of $RES0URCE 

made for each resource of 




a problem 




3.5.6 $SCHEDULE 



OPERATIONS MODEL DATA STRUCTURES 


The problem descriptions of Section 3.4 can be represented as 
hierarchical data trees compatible with the PLANS language. 

THE USER-DEFINED DATA TREES ARE: 


$RES0URCE 


$PR0CESS 


Describes the resources of 
the system 

Describes the activities 


of the system 

$0PSEQ Describes the operational 

sequences of the system 
^OBJECTIVES Describes the objectives 

and constraints of a problem 

The problem descriptions of Section 3.4 can be utilized in PLANS 
programs to generate schedules and/or resource allocations. The 
information associated with problem solutions can also be repre- 
sented in hierarchical data trees compatible with the PLANS Ian- . 
guage. 


THE PROGRAM-CREATED DATA TREES ARE: 

$J0BSET Describes each single occur- 


rence of a process of a 
problem 


$$CHEDULE 

Describes each job and the 
associated resources that 
are assigned to a specific 
time interval 

ASSIGNMENT subnode 

Describes the assignments 

of $RES0URCE 

made for each resource of 


a problem 




3.5.6 $SCHEOULE 


$SCHEDULE contains the cm8WeT to the scheduling problem. That 
is, it contains the same Jobs as $J0BSET , but now each Job in- 
terval contains specific times (i.e., not relative) and specific 
resources have been identified for each job. No resource or job 
alternatives exist In $SCHEDULE because these selections have 
been made and no temporal relationships are needed because absolute 
times have been assigned for each job. Resource intervals rela- 
tive to the job interval have been replaced with absolute times. 

In other words, the schedule has been oonovetized (see Fig. 3. 5. 6-1 
for the basic structure). $SCHEDULE consists of any number of 
schedule units, which contain of all of the substructure for any 
one job Identifier. This schedule unit is considered the smallest 
element that may be scheduled. The individual schedule unit 
contains all Information necessary to maintain a record of re- 
source allocations made and corresponding descriptors that apply 
to the specified resource and time interval. 
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3.5.7 Assignment Subnode of 
$RESOURCE 






3.5.7 Assignment Subnode of SRESOURCE 



OPERATIONS MODEL DATA STRUCTURES 


The problem descriptions of Section 3.4 can be represented as 
hierarchical data trees compatible with the PLANS language. 

THE USER-DEFINED DATA TREES ARE: 

$RES0URCE Describes the resources of 

the system 

$PR0CESS Describes the activities 

of the system 

$0PSEQ Describes the operational 

sequences of the system 
$OBJECTIVES Describes the objectives 

and constraints of a problem 

The problem descriptions of Section 3.4 can be utilized in PLANS 
programs to generate schedules and/or resource allocations. The 
information associated with problem solutions can also be repre- 
sented in hierarchical data trees compatible with the PLANS lan- 
guage. 

THE PROGRAM-CREATED DATA TREES ARE: 

$J0BSET Describes each single occur- 

rence of a process of a 
problem 

$SCHEDULE Describes each job and the 

associated resources that 
are assigned to a specific 
time interval 


ASSIGNMENT subnode 

Describes the 

assignments 

of $RES0URCE 

made for each 

resource of 


a problem 




3.5.7 ASSIGNflENT Subnode of $RES0URCE 

While the basic inputs to $RES0URCE consist of resources and 
their characteristics as defined by a user, an equally important 
function of the $RES0URCE tree is to maintain a record of all al- 
locations made for each resource. Even though these allocations 
are handled by the scheduling program, the close relationship 
between the initial resource descriptions and the subsequent des- 
criptions brought about by assignments to certain activities, 
justifies the existence of both in the same data tree. Therefore, 
as shown in the $RES0URCE tree in Fig. 3. 5. 1-1, all assignments 
are recorded as a substructure to the ASSIGNMENT node of $RES0URCE. 

Assignments are arranged by increasing start times with equal 
start times being ordered by earliest end time. Such an ordering 
will facilitate the checking for resources by subsequent schedul- 
ing attempts. Each assignment is indicated on the $RES0URCE tree 
diagram by a null labeled (<?) node. The assignment will consist 
of an INTERVAL, DESCRIPTORS, and any other information included 
as a corresponding part of the schedule unit from which the up- 
date of the assignment file is made. Library modules WRITE__ 
ASSIGNMENT and UPDATE_RESOURCE have been designed to accomplish 
this update. Additional identification information will have to 
be included in the basic schedule unit to allow subsequent un- 
scheduling. These data, to be included as first-level subnodes 
to the null assignments nodes, could include the problem name, the 
operations sequence involved, etc. The library module UNSCHEDULE 
has been designed to remove assignments from the $RES0URCE tree. 
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The DESCRIPTORS portion of the assignment structure allows 
subsequent investigation to determine the histovy of any given 
resource. That is, the state of an item-specific resource or 
the partitioning and corresponding quantities of pooled resources 
may be determined as a function of time. The library module 
RESOURCE PROFILE is designed to determine the quantity in a re- 
source pool as a function of time for the pooled resources with 
implicit descriptors. Two variables determine the available 
quantity of a pooled resource. The assignments affect the avail- 
able quantity because any resources assigned are assumed to be 
unavailable during the assignment interval. Secondly, resources 
may be either generated or deleted as the result of a process. 

For purposes of creating a profile, it is assumed that any quantity 
deleted or generated is reflected at the end time of the process 
interval. This would be indicated by an appropriately labeled 
FINAL.DESCRIPTOR with a value of either GENERATED or DELETED-. The 
corresponding quantity would be indicated with the subnode QUANTITY. 

DESCRIPTOR_PROFILE is a module that uses the assignment infor- 
mation in $RES0URCE to deterqjine the history of changes to the 
descriptors for an item-specific resource. These resources have 
an initial description that is updated as assignments are made. 
Obviously, if a resource is being considered for a specific proc- 
ess, it will be necessary to know the current set of descriptors 
that apply for a time interval of interest. Also, recognizing 
that an item— specif ic resource may be assembled with other re- 
sources to generate a new resource, a FINAL DESCRIPTOR of DELETED 
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could apply. Therefore, when assessing the availability of an 
iteiTi“Specif ic resource, it is not sufficient to check only for 
conflicting assignments. A further check must be made of the 
final descriptors for the most recent assignment to ensure that 
the resource was not deleted. Similarly, an item specific re~ 
source may be generated (or regenerated) by the disassembly of 
a resource. 
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6 Heuristic and Mathematical Programming 
Solution Techniques 



3.6 heuristic and MATHEMATICAL PROGRAMMING SOLUTION TECHNIQUES 

An analysis of the state-of-the-art in computerizable shed- 
uling techniques leads to the conclusion that two major bodies 
of standardized methodology are available (see Appendix), The 
first is referred to here as project scheduling' and is based on 
heuristic scheduling rules. The second is called mathematical 
programming and is based on procedures that produce mathematically 
optimal solutions. The specified PLANS module library contains 
routines in both classes of solution methods. However, each class 
of methods is capable of dealing with problem models that have 
only limited generality or dimensionality. Problems that are 
described with more general models and/or higher dimensionality, 
however, will be solved by building problem-dependent logic. While 
PLANS is designed to aid in programming such logic, the analyst 
will make better use of the PLANS programming system by describing 
his problem in a format that makes one of the two standardized 
methodologies applicable. If this is done, the capabilities rep- 
resented in the module library can then be applied, and will per- 
mit much more rapid program development and checkout. 

The purpose of this section is to describe the characteristics 
of the problem models that are compatible with existing standard- 
ized solution methodologies so that the user of both PLANS and 
the PLANS module library will have the maximum capabilities avail- 
able to him. It should be noted at this point that nothing in 
PLANS precludes its use with nonstandard methodologies. To be sure, 
PLANS makes customized scheduling logic much easier to program. 
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Similarly, the module library is not limited to capabilities as- 
sociated with project scheduling, mathematical programming, or 
solution methods; in fact, many of the modules perform functions 
that must be performed in typical problem- dependent scheduling 
logic . 

Combination of the generalized network modules and the re- 
source allocation and smoothing modules specified for the module 
library constitutes a project scheduling system that is applicable 
to very large problems that have the problem models described 
above. The logical relationships of these modules is shown in 
Fig. 3.6-1. The collection of project scheduling modules provides 
state-of-the-art solution capability for that class of problems. 

It should be noted that each individual module performs a separ- 
able and useful function in its own right and thus may be used in 
any custom-made logic that the user designs. Executive modules 
(i.e., NETVJ0RK_EDIT0R, CRITICAL_PATH_PROCESSOR, and HEURISTIC_ 
SCHEDUL ING_PR0CESS0R) are also provided, however, that call other 
modules in order to execute a particular solution strategy. This 
strategy produces near-minimal time schedules, which satisfy both 
resource level constraints and network constraints (precedences) 
and also produce smoothed resource demand profiles. 

The problem characteristics that are accommodated by the 
PLANS project scheduling modules include those described in Sub- 
sections 3.4.1 through 3.4.5 and illustrated in Fig* 3.6-2. In 
addition, project scheduling techniques can be applied to more 
general problem descriptions by applying special reformatting 
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(a) Network-Processing Modules Calling Hierarchy 



(b) Critical-Path Modules Calling Hierarchy 



Cc) Heuristic-Scheduling Modules Calling Hierarchy 


Fig, 3.5-1 

Project Schedule Syetem within the PLANS Module Library 
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JOBS AND THEIR RELATIONSHIPS TO OTHER JOBS 



RESOURCES AND THEIR RELATIONSHIPS TO JOBS 
Fig, 3.&-2 

Problem Models for Plans Project Scheduling Modules 
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techniques. Examples include creating dummy processes and regarding 
item-specific resources as pools of the quantity one. Studies 
are underway to identify and automate such reformat ing techniques 
that will extend the capabilities provided by project scheduling. 
Results will be reported in subsequent documentation. 

In a strict sense, the problem characteristics that can be 
handled by mathematical programming methods are not limited. It 
is the dimensionality of the problem that limits its compatibility 
with mathematical programming techniques. All scheduling problems 
that can be solved using mathematical programming techniques can 
be characterized as small vn dimensionality. Such problems may 
occur in preliminary scheduling or may represent intentional sim- 
plifications made for the purpose of establishing performance 
goals or limits. If a problem involves only a small number of 
processes, each with a small number of resources, and if few al- 
ternatives exist for choosing between resources or processes, 
then mathematical programming solution techniques could be ap- 
plicable. An Increase in generality of any problem model leads 
to a very rapid Increase in the dimensionality of the correspond- 
ing mathematical programming formulation. For example, jobs that 
require nonconstant quantities of resources, as illustrated in 
Fig. 3.6-3, lead to additional choices (i.e., decision variables) 
and, therefore, to an increase in deimensionality . 
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Fig. 3.6-S Example of Eonoonat ant Resource Demand Fro file 

It follows that model simplicity is an indirect necessary con- 
dition for using mathematical programming techniques for scheduling. 

Some problems associated with resource allocation may have 
small enough dimensionality to be amenable to mathematical 
programming techniques. An example is the development of a 
set of compatible combinations of resources such as grouping 
payloads that have composite length, weight, and power require- 
ments that fall below a set of limits. The PLANS library contains 
modules, called COMPATIBILITY_SET_GENERATOR and FEASIBLE__ 
PARTITION_GENERATOR, which apply to this problem. They are based 
on quasi— enumer at ive techniques and produce mathematically op- 
timal solutions. 

Other problems with small dimensionality can be solved with 
other PLANS mathematical programming modules. Figure 3.6-4 rep- 
resents a decision structure that leads either to an appropriate 
algorithm choice, or to an indication that mathematical programming 
techniques are not applicable. This simple diagram contains 
order-of-magnitude decision thresholds concerning dimensionality 
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and should assist the problem analyst in determining whether he 
should consider using mathematical programming. Secondarily, 
the figure is useful in suggesting characteristics of his problem 
that prevent the applicability of existing mathematical programming 
methods. Such knowledge could lead to minor restructuring of the 
problem model to take advantage of logic from the module library. 

The use of Fig. 3.6-4 presumes the ability to scope the di- 
mensionality of a problem. For estimating purposes, the dimen- 
sionality of a problem can be approximated by summing (over all 
jobs) the number of time intervals during which each job may 
start. The upper bound on the number of intervals during which 
a job may start is, of course, the number of intervals in the 
scheduling horizon being considered. If a critical path analysis 
is performed, the user can determine the exact number of inter- 
vals for each job as the number of slack intervals for that job. 

The tests for Generalized Upper Bounding structure (abbreviated 
GUB in Fig. 3.6-4) refer to a special structure within the tableau 
in linear programming that permits the use of this technique. 

The GUB structure arises in problems that require the selection 
of one, and only one, candidate from each of several groups of 
candidates. For example, in a scheduling problem one, and only 
one, start time must be chosen for each job (from the groups of 
candidate start times for that job). No jobs may be left out and 
no jobs may be assigned more than one start time. Another example 
where the GUB structure would occur is in assigning personnel with 
special skills to a job requiring one electrician, one plumber, one 
mason, etc given that sets of personnel with these skills exist. 
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ILLUSTRATIVE EXAMPLES 


^,0 

4.1 ORDERING OF A PRECEDENCE NETWORK 

4.1.1 Problem Statement 

In Section 2,0 of this volume, the logic of the module 0RDER_ 
BY_PREDECESSORS is used to illustrate the PLANS language features. 
The same example is repeated here with emphasis placed on how the 
data structures are modified as the logic is executed. A simple 
four-job network is used for illustration; the network can be 
depicted as shown in the sketch. 



The problem is simply to generate, from a randomly ordered list 
of jobs, an ordered list that has the property that any job will 
appear in the ordered list only after all its predecessors have 
appeared. 

4.1,2 Problem Model 

For this simple problem, the input network information is 
provided in a tree called $J0BLIST that, initially, has the 
structure shown in Stage 1 of Fig. 4.1-1. 
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SJOBLIST $NAME_LIST $ORDERED_UST 



JOB C JOB D JOB B JOB_B 



SJOBLIST $NANE_LIST $ORDERED_LIST 



JOE B JOB B JOB C JOB_D 


Fig, 4.2-1 Data Sti*uoturee Illustrating ORDER BY PREDECESSORS 


164 



iD00'^cntn45‘CA>rv)i--‘ 


4.1.3 Program Logic 

The $J0BLIST tree shown at Stage 1 is passed as a parameter 
to the module, ORDER_BY_PREDECESSORS (see Fig. 4.1>2). Because 
$NAME_LIST is declared to be local to the module, it is empty each 
time the module is entered. $ORDERED_LIST is usually empty, but 
may contain jobs that are to precede all jobs in $J0BLIST. This 
allows ORDER_BY_PREDECESSORS to be restartable, in case a re- 
quired job was missing from $J0BLIST on a previous call to 0RDER_ 
BY_PREDECESSORS. $ORDERED_LIST is passed to the module as a 
parameter. Its initialization is the responsibility of the call- 
ing program. 

ORDER BY_PREDECESSORS: PROCEDURE ($OOBLIST, $ORDERED_LIST) ; 

DECLARE $NAME_LIST, $TEMP LOCAL ; 

LOOP : 

GRAFT $J0BLI ST. FIRST: (ELEMENT. PREDECESSOR SUBSET OF $NAME_LIST) 
AT $TEMP; 

IF $TEMP IDENTICAL TO $NULL THEN RETURN ; 

$NAME_LIST (NEXT) = LABEL ($TEMP) ; 

GRAFT $TEMP AT $ORDERED_LIST (NEXT) ; 

GO TO LOOP ; 

10 END 0RDER_BY_PREDECESS0RS ; 

Fig. 4.1-2 PLANS Subroutine for Ordering Jobs by Predeoessors 
Since $NAMEJ_IST is initially empty, the GRAFT statement at 
line 4 searches for the first job in $J0BLIST that has no pre- 
decessors (J0B_B) , removes that job from $J0BLIST, and places it 
at $TEMP . Because a job was found (i.e., because $TEMP is not 
null) , line 6 fails to cause a return. The name of the job found 
is, therefore, added to $0RDERED_LIST . The GO TO statement at 
line 9 then starts the process over again at LOOP . The tree 
status at this point is shown in Fig. 4.1-1, Stage 2. 

165 



The GRAFT statement at line 4 again searches for the first job 
in $J0BLIST whose predecessors are a subset of $NAME_LIST. In 
this case, $NAME LIST contains only the name, J0B_B . Thus, the 
first job (J0B_C) in $J0BLIST that either has no predecessors or 
has only JOB B as a predecessor will satisfy the condition and be 
removed from $J0BLIST and placed at $TEMP . The exit test falls, 
the name J0B_C is added to $NAME_LIST, and the job itself is 
removed from $TEMP and added to $ORDERED_LIST . The tree status 
at this point is shown in Fig» 4.1-1, Stage 3. Note that the 
entire substructure representing information about J0B_C is now 
in $ORDERED_LIST. 

The third pass starting at LOOP transfers J0B_D to $0RDERED_ 
LIST because its only predecessor, J0B_B, is named in $NAME_LIST. 
The tree status at this point is shown in Stage 4. 

Now that both J0B_C and J0B_D are named in $NAME_LIST, the 
conditional GRAFT statement is satisfied by J0B_A, which is there- 
fore moved to $ORDERED_LIST , yielding the status shown in Stage 5. 

Finally, the GRAFT statement at line 4 fails to find in 
$J0BLIST (which is empty) a new job whose predecessors are in 
$NAME_LIST. A null node is, therefore, placed at $TEMP , causing 
the exit test (line 6) to succeed. Note that the module would be 
exited if the conditional GRAFT statement failed even if $J0BLIST 
were not empty. This condition would indicate a cycle or a miss- 
ing job in $J0BLIST. It is the responsibility of the calMng 
program to test for this condition if such a test is considered 
necessary. 
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4.2 


PAYLOAD GROUPING 


4.2.1 Problem Statement 

The problem is to find a composite payload whose character- 
istics satisfy Shuttle Orbiter limits. For simplicity, we restrict 
the characteristics to be those that can be evaluated by summing 
the properties of the individual payload (e.g., length, weight, etc). 
Any combination of payloads that satisfies all the Shuttle limits 
is considered a candidate for a mission. The best composite pay- 
load is to be selected by an existing routine. Therefore, the 
logic to be written must find all feasible combinations and pass 
those combinations to the selection routine. A composite payload 
could consist of a single payload, a pair of payloads, a triplet 
of payloads, etc, i.e. combinations of order 1, 2, ... up to a 
prescribed maximum order. For example, payload 12 could, itself, 
be a feasible composite payload as could the triplet consisting 
of payload 12 , 5 , and 17 . 

V.2.2 Problem Model 

This problem is not, in the strictest sense of the word, a 
scheduling problem because no assignment of times to the activ- 
ities is involved. However, neither PLANS nor the library modules 
have been designed with such a limited view of scheduling in mind. 
This problem deals with the characteristics of resources that can 
be described within the $RES0URGE tree structure, as: 

$RES0URCE 

SHUTTLE_WITH_KICK_STAGE 

i 

LIMIT 

BAYJ.ENGTH - 32 
WEIGHT - 4400 
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PAYLOAD 

ASOOl 

CHARACTERISTICS 
LENGTH - 13 
WEIGHT - 1807 

PH007 


The information needed to generate the candidate-feasible 

combinations and to call the payload selection routine can be 

arranged within the $0BJECTIVES structure as shown below: 

$0BJECTIVE 
FIG_0FJ1ERIT 
i - MINIMIZE 
i - NUMBER 
CONSTRAINT 

MAX_IN_C0MB0 - 3 

4.2.3 Program Logic 

The logic consists of nested loops of PLANS code. The inner- 
most loop sums one characteristic over all payloads in a par- 
ticular combination. This summation is repeated for each char- 
acteristic as the next higher loop is executed. The combination 
loop, a unique capability of PLANS, generates each payload com- 
bination of order K, where K ranges from 1 to the value of MAX 
IN_C0MB0 in the outermost loop. The PLANS code is shown below. 


1 

2 

3 

4 
3 
6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 
19 


FlNO_BtST_C0MPObTTF_P4YL0ftnj kPOCFDURF ( %08 JECT I VE S ♦ ^kESOURCE) t 
/* 3ENEHATE ALU IMTERNALLY Ft.A&lRl.F PAYLOAD COMBINATIONS, */ 

DO K = 1 TO TOoJfCTIVFS, CONSTRAINT, max_IN_COMRO * 

DO FOR ALL CO.-tHT NAT TONS OF -sRtSouHCF .PAYLOAD TAKEN K AT A TIME » 

00 J = 1 T \ MlJNRFP ( >pFS('IIMCF,SHUTTLF_WITH_KICK_STaGF ( 1 ) .LIMIT) t 

S.SUM(J) = o' « 

DO L = ] TO K » 

%SUM(J) = 'tiSMMfJ) ♦ iCOMRiNAT lON(L) .characteristic (J) l 


FND ! 

IF SSUM(J) > 5PFS0UWCF ,ShuTTLF_WITH_K1CK_STAGE ( 1 ) .LIMIT U) 
Tmfn Go to EMD^CoMBo^i.onp t 
END » 

iFEASlRLF«SET (NFXT) = tCOWRINATlON I 
GRAFT SSUM AT iFF AS I RLE.-SE T ( u AST ) , SUMS I 
ENU_C0 mB<)_l OOP* EKM) ) 
end t 

CALL BESTSETlSOBJtCTlVES. iFFASIRLE^SFT.SREST) I 
>««ITE iBEST I 

END FIND_BEST_CO.--POSITF_PAYLOAD I 


Reproduced from 
best available copy. 
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The code presented assumes that the subroutine BESTSET has 
the capability to interpret the information and structure of 

$OBJECTIVES. 


Notice should be taken of the use of the special indices* 

NEXT and LAST, in statements 13 and lA. These statements add a 
new combination of payloads to $FEASIBLE_SET . Because PLANS is 
a tree manipulation language, the structure of the data trees 
actually changes during program execution. 

As the combination loop is executed, the structure $C0MBINATI0N 
is maintained. $C0MBINATI0N is a special tree that does not 
actually have subnodes of its own. Instead, $C0MBINATI0N is 
maintained, with a set of pointers, in the already existing 
structure from which the combinations are to be formed ($RES0URCE. 
PAYLOAD) . This economizes on time and storage by avoiding un- 
necessary duplication of data. For a second-order combination, 
it might look like: 


$C0MBINATI0N 

ASOOl 

CHARACTERISTIC 
LENGTH - 13 
WEIGHT - 1807 


PL015 

CHARACTERISTIC 
LENGTH - 27 
WEIGHT - 3645 


SCOMBINATION 
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where both payload designators are first order subnodes of 
$C0MBINATI0N. If this combination were feasible, the statement 
$FEA$IBLE__SET (NEXT) = $C0MBINATI0N would cause the following 
modification of $FEASIBLE SET. 


Structure prior to 

Structure after 

Statement execution 

Statement execution 


$FEASIBLE SET 

$FEASIBLE SET 

t 

i 



ASOOl 

or 

CHARACTERISTIC 


LENGTH - 13 


WEIGHT - 1807 

$FEASIBLE_SET 

PL015 


CHARACTERISTIC 
LENGTH - 27 
WEIGHT - 3645 
or 


$FEASIBLE SET 
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The next statement, GRAFT $SUM AT $FEASIBLEJSET(LAST) .SUMS results 
in: 


Structure prior to 
Statetnenc execution 


Structure after 
Statement execution 


$SUH 
i - 40 
4 - 5452 


$SUM 



5452 


$SUM 


$SUM 

o 


$FEAS1BLE_SET 

4 


ASOOl 

CHARACTERISTIC 
LENGTH - 13 
WEIGHT - 1807 

PL015 

CHARACTERISTIC 
LENGTH - 27 
WEIGHT - 3645 

$FEASIBLE SET 



$FEASIBLE_SET 

4 


PL015 

CHARACTERISTIC Q CHARACTERISTI C 

LENGTH^ WEIGHT (J5lEN6TH^ WEIGHT 
13 1807 27 3645 


ASOOl 

CHARACTERISTIC 
LENGTH - 13 
WEIGHT - 1807 

PL015 

CHARACTERISTIC 
LENGTH - 27 
WEIGHT - 3645 

SUMS 
4 - 40 
4 - 5452 


SFEASIBLE SET 



40 5452 


LENGTH^ weight!^ LENGTH I, J WEIGHT 
13 1807 27 3645 
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Note that because the assignment statement 13 builds a new node 
in $FEASIBLE_SET , the GRAFT statement (14) must refer to the LAST 
(not NEXT) node If the SUMS are to apply to the correct combina- 
tion. If the code had been incorrectly written as: 

$FEASIBLE_SET(NEXT) = $C0MBINATI0N; GRAFT $SUM AT $FEASIBLEJET 
(NEXT). SUMS; 


the structure of $FEASIBLE_SET would have been: 


$FEA$IBLE_SET 

i 

i 

i 

ASOOl 

CHARACTERISTIC 
LENGTH - 13 



Incorrect code causes the 
loss of the association of 
these data. 


4,2.4 Changes to Problem Scope 

It can be recognized that the code is independent of the number 
of payloads in the problem, the number of characteristics being 
considered, and the maximum number of individual payloads allow- 
able in any combination. Furthermore, it is possible to write the 
BESTSET logic in PLANS to interpret tree data in $OBJECTIVES so 
that changes in the problem objectives are easily accommodated. 

PLANS permits coding of this routine to be even less sensi- 
tive to problem changes than the code illustrated. Suppose, for 
example, the power requirements and weights of instruments were 
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to be summed to check for feasibility as a part of a sortie 

module design. The appearance of the label PAYLOAD in the code 

is therefore restrictive. The problem would have been avoided 

by placing the resource name to be considered in a special place 

in the data structure such as in $OBJECTIVES as follows:' 

lOBJECTIVES 

FIG_OF_MERIT 
t - MINIMIZE 
t - NUMBER 
CONSTRAINT 

MAX_IN_C0MB0 - 3 
PROBLEM_RESOURCE - PAYLOAD 

The statements in the illustrated coding that contain the label 
PAYLOAD could have been coded with an indirect reference. For 
example: 

DO FOR ALL COMBINATIONS OF 

$RESOURCE.#($OBJECTIVES.PROBLEM_RESOURCE) 

TAKEN K AT A TIME ; 

Thus to change from payloads to instruments would be accomplished 
by adding instruments to $RES0URCE and changing the value of the 
PR0BLEM__RES0URCE node of $0BJECTIVES. 

4 . 3 PROJECT SCHEDULING 

4.3.1 Problem Statement 

A project consists of 11 activities, each requiring resources 

from three different resource pools. To be specific, consider 

\ 

each pool to be a manpower pool , containing six men with a common 
skill. The activities in the project are related to each other 
by simple precedence relations; i.e., certain activities cannot 
begin before others are finished. The objective of the schedule 
is to find the earliest time that all jobs can be completed with- 
out using more from any pool than are available. 
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4.3.2 Problem Model 


This problem is precisely the basic project scheduling model. 
The characteristics that make it so are: 

1) Relationships between jobs (temporal relations) are simple 
predecessors ; 

2) Resources required are pooled resources with no special char- 
acteristics that are altered after an assignment. (Pooled 
resources with implicit descriptors only, i.e., with no 
explicit descriptors) . 

The temporal relations of the problem can be illustrated by a 
network diagram. The diagram of Fig, 4.3—1 shows the job dura- 
tion below each job and the quantitites of required resources 
from each of the three pools above each job. 



Fig. 4.3-2 Network Diagram for Progeot Scheduting 
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The standard data structures presented previously accommodate 


project scheduling information. Relations between jobs are in- 
cluded in the structure $0PSEQ which, for this problem, would 


look like: 

$0PSEQ 

PROJECT - A 
A 

TYPE - PROCESS 
B 

TYPE - PROCESS 
C 

TYPE - PROCESS 
TEMPORAL_RELATIONS 
PREDECESSOR 
t - A 
D 

TYPE - PROCESS 
TEMPORAL_RELATIONS 
PREDECESSOR 
i - A 

E 

TYPE - PROCESS 
TEMPORAL_RELATIONS 
PREDECESSOR 

- D 
F 

TYPE - PROCESS 
TEMPORAL_RELATIONS 
PREDECESSOR 

- D 
G 

TYPE - PROCESS 
TEMPO RAL_RELAT IONS 
PREDECESSOR 
<t - B 
H 

TYPE - PROCESS 
TEMPORAL_RELATIONS 
PREDECESSOR 
i - F 
^ - G 
I 

TYPE - PROCESS 
TEMPORAL_RELATIONS 
PREDECESSOR 
i - C 
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J 

TYPE - PROCESS 
TEMPORAL_RELATIONS 
PREDECESSOR 
t - I 
- E 
K 

TYPE - PROCESS 
TEMPORAL_RELATIONS 
PREDECESSOR 
(t - J 


The relationships between jobs and their resources are described 
in the $PR0CESS tree. For this project scheduling problem, 


$PR0CESS looks like the following: 


$PR0CE$S 

A 


REQUIRED_RES0URCES 

MANPOWER 

LABOR^l 

i 

DESCRIPTORS 

i 

INITIAL 

QUANTITY - 3 

LABORJ 

t 

DESCRIPTORS 

i 

INITIAL 

QUANTITY - 2 

LABOR J3 

DESCRIPTORS 

INITIAL 

QUANTITY - 1 

DURATION - 3 


REQUIRED_RES0URCES 

MANPOWER 

LABORJ 

DESCRIPTORS 

i 

INITIAL 

QUANTITY 


- 4 
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LABORJ . 

DESCRIPTORS 


DURATION - 5 


INITIAL 

QUANTITY - 2 


The descriptions of the resources modeled in the system are de- 
fined in the $RES0URCE tree. For this problem, $RES0URCE would 
include; o 

$RES0URCE 

MANPOWER 

LABORJ 

CLASS - POOL 
INITIAL_PROFILE 
NORMAL 

QUANTITY -6 

LABORJ 

CLASS - POOL 
INITIAL_PROFILE 
NORMAL 

QUANTITY-6 

LABORJ 

CLASS - POOL 
INITIAL_PROFILE 
NORMAL 
i 

QUANTITY -6 

The fact that there is a single occurrence of the operation 
sequence PR0JECT_A, is modeled simply by constructing $OBJECTIVE 
as shown below. The PROBLEM RESOURCE node identifies MANPOWER 


as the critical resource to be considered in this problem. This 
allows the programmer to use indirect references, thus making 
his code more generally applicable. 
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$OBJECTIVE 

OPSEQ 

PR0JECT_A 

TYPE - OPSEQ 

PROBLEM_SESOURCE - MANPOWER 


4»3.3 Program Logic 




4.3.4 


Because this problem is purely a project scheduling problem, 
the project scheduling routines from the module library apply 
directly. The recommended method of solution for this example 
would be to use the time-progressive heuristic of the RESOURCE 
ALLOCATOR module. Volume III of this report contains the de- 
tailed functional specifications for this module, and the solu- 


tion for this example problem that results from the application 
of the heuristic procedures is specified in RESOURCE ALLOCATOR. 

The PLANS program code to solve this example merely calls the 
specified library module called RE$OURCE_ALLOCATOR . Therefore, 
the code is simply: 

PHOJEC l_SCHFr)UUlwCiJ J 

iOPSFiJ* kl'k'tct SS» » 1 -ftH JpCTIVKS. 1 NTETI’EH * » T AkT »f MD I 

= iririjtcT|VES.Pk(WLe-_WESf>UMCt f 

CALL «*$PM0C£S5*IN1E0EB.4J0BS(:T( I 

i>0 1 = 1 TO kO'HtPfjwFSOUPCt.B HTYPE) ) I 
CALL HF.SIIUMCK^PWOK 1L!‘ ( FSOtJWCF « 1. T YPE * 

LiHFL (”fcr>hSOUPrE ,« (tTYPf.) ( I) ) .STawT » SPPOF I| E) « 
bBAFf tPP*lF ll.F 4T %PPijFfLF.S(MF*T( I 
r.NO i 

CALL btSOU«Ct_At LIIC&TfiFni,j:iKSET.1.PHllf II FS.1iSCrifcOULt> « 

PkirE tSCHtt>li[ t ; 

ENIl PHOJfcCT_SCMe.iUl I 110 ( 


Alternative Approach 


An alternative to the time-progressive heuristic scheduling 
strategy, used within the RESOURCEJ\LLOCATOR module, is a time- 
transcendent strategy, A single time— transcendent strategy with 
sufficiently general applicability cannot be specified and there- 
fore is not provided in the module library. However, the PLANS 



178 



I code for constructing such a solution strategy is quite simple. 
To Illustrate this, consider the logic of Fig. 4.3-2, which is 
a time-transcendent logic. For the example problem presented, 
the program shown in Fig. 4.3-3 could be written to implement 
the logic on the flow chart. 

4.3.5 Changes to Problem Scope 

It should be noted that this program is independent of the 
total number of jobs, the definition of their predecessor rela- 
tionships, the number of resource pools, the problem resource 
type, and the time increment. That is, in order to vary these 
problem characteristics, the programmer needs only to change the 
input data. However, throughout this example it has been as- 
sumed that IJOBSET contains only one SUBNET_ID subnode. This 
will be the case for this particular example problem because 
there is only one subnode of $0BJECTI VES . OPSEQ ; but, generally, 
there will be several such subnodes. This problem can be elim- 
inated by inserting the following block of code after the CALL_ 
6ENERATE_J0BSET statement near the beginning of the program. 

DO 1=1 TO NUMBER ($J0BSET); 

DO J=1 TO NUMBER ( $J0BSET{ I ) ) ; 

GRAFT $J0BSET(I)(J). AT $JOBLIST(NEXT) ; 

END; 

END; 

PRUNE $J0BSET; 

This code eliminates all of the SUBNET_ID nodes found in $J0BSET. 
It creates a new data tree called $J0BLIST that contains all of 
the ^'job" nodes one level below the root node. Therefore, in 
the remainder of the program all occurrences of $J0BSET(l) should 
be replaced with $J0BLIST. 
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h 

'ff 



START 


Read Input Data 


Apply Critical Path Method Generating 

1) Earliest start times 

2) Latest start times 

3) Total slack 


Order the list of jobs by 

1) 

Total slack 

2) 

Earliest start times 

3) 

Duration 


Check the job list. 

If any job occurs before its 
predecessors, move its 
predecessors to a position 
immediately above the job in 
the list. The predecessors 
should be moved in order of 
smal lest 

1) Latest finish time 

2) Total slack 

3) Duration 


Select the first job in the ordered list 


Select next job in list 


Select the earliest start time 



for the current job 


STOP 


^scheduled?. 


Model Interface 


is 

current 

job 

resource-feasible 
at this 


Schedule the current job 
at the desired time and 
write the associated 
resource assignments 


Fi,g. 4.3-2 

Flew Logic for* Time Transcendent Prog eat Scheduling Algorithm 

















/* THIS PPOf-KAM USfS A TImF- 1 PANSrENDfNT STRATEGY Tl> SOLVF THE 
/* BASIC PRoJ^CT SCHEOIILJNR ‘'POhLF^i. 


• / 
• / 


PHOJEC r_SCHEOULlHUJ PPOCEOUPK : 

REAU SOPJEClWFSt SOPSEO* +RPOCFSS* SRESOURCEi OELlA_TlMEt INTEGER I 

CALL BENE»Aft_JOHSFT (^ONjr.CTl»/F«:*!KnpSECi*»P«<)CESS»INTeGtP* IJOBSET) « 

CALL CRlTTCAl.3PATH_CAI,tULA1nR ($.iOPSET) I 

ORDER 'liJ0RS>F>7i) BY -FLOA T , TOT At. ♦ -STAR.T .EARLY » - JOm_IhTERVAL .END, I 
NUMMER_OF_JObS = NUmHFk (SiJi'RSET ( U ) « 

/* 

THIS LOOP (iRiiKOS THE JOKS BY DOtr>ECLSSORS. WITHIN EACH GROUP OF 
PHEOECFS^URS The JOBS AKF rut T»^1 ASCEnOING order ACCOROING TO LATFST 
finish tires, total SLAC^* ANO IHJRATJOn. */ 

DO 1“1 TO N'Jr'iER^OF^JOES { 

SCAN_JUHSET» 

IF NtjopSET ( n (I ) . TFBPoRAL^KFI ATioNS.PMEOECESSORS subset of 

SNAMFLIFT 

THEM enamel I ST (NE AT) = LAMFL I i JOBSt T ( 1 ) ( 1) > » 

ELSE OU I 

OU KoI*l TO NUHHFn^nF_.IOtTS * 

IF LAHM. l iJOHSKT (1 ) (K) ) SUBSET OK 

’’'jOHSrT (I ) ( T > .TEMPORaI relations.ppeoeckssors 

Then GRAFf 1.00PSFT t n (K> at STERPt -iEAT) I 
F.nO i 

Oh >tR J>TFNp «Y t IMISh.LATE. FLOAT. TQTAL. DURATION ? 

UO L=1 to NUM4K- ( tTF‘«P> i 

GRAFT I^SFO^ 't.r£MP(l> AS SJO'TSETtlMl) I 


FNU t 

OU TO SCAN_JUmST T I 
ENf- I 

END I 

PRUNE *NAMEL1‘-T t HTYPF = <-objfctives.problem_rf.sourcf « 


/* 


Jt)^ ) 1ST AND SCHEQULfcS EACH JOB AS SOON 
WhirH all of its REUUIHEI) RFSOURCES ARF 


TIhF = SJOBSFT(l> (J) . start. EARLY » 


Time. 4PROFILF1 I 


This loop bOfS through THr 

AS A TIMF is DFTF.RMTmEO Ia. 

available. “/ 

DO u»l TO NUH-iER_OF_JOBS I 
CHECK^HESOURCE^A 'fATL ARILl I T t 

UO <al Tu .V.UPHER ( 'fiRtSOU*-'CF«# t'*'TYPE> ) » 

CALL RKSOURCF^pI-^OF ILt 1 1>RE<50U«CE ♦ 4TYPE. 

I, ABFL (HlRPSOUPCe.W (STYRF) (K J > . TiMc 

fPROt-lLE » IN_USF ( 1) ,0 'JAmTITY * 

«Jt'H<<tT(l) (I) .RFIJUIRKO PFsnURCES.R (STYPE) (G)(1) .UESCRIPTORS 

( U . INITIAL, QUANTITY 

> 'bRt.-SrtUHCF.o ( aTY> F,) (K) . TNTTIAL_PR0F1LE. NORMAL ( 1 > .QUANTITY 
THf, N L)0 ( time = TTHF * nFLTA_TIME \ 

GO TO CHECK_i<FSOUPCF_AVAlLARILlTY I 

two I 

) 


IF 


END 


/* 


ING THE ASSIGNMENT 


: 

SJDHStTd) (U) .DURATION » 




INF OH 


NOW THF job caw HF SCHEDULED BY UPpA 
FUuNU IN IHE (WEE, SwESOUHCe . »/ 

a>ASSlGNMENT_UNIT, IwTFwV^L. START = TIME 
SASSTGNMKNTJJNI r. interval .END = TIME ♦ 

UO L=1 TO •UmhERI^RF.SOU'-XE.a (FTYPE) ) I 

NFFoED^aMT = ^.jnHSET< 1) (Jl ,RF0UlHEn_RFS0U«CE5.A(*TYPE> (L» (D . 

descriptors m . initi al.quantity « 




IF NEFUFD^AMT ->= 0 

then do » 

%ASSIG.NHf;NT_UNIT,nESrRlPTOR< 1 ) . INITIAL. quantity = 

NEEDEO^AMT I 

Call rri ie.assignmemt i sassignwent^uni r « 

SBESnURCe.A (STYPE) <L) .ASSIGNMENT) » 


END » 

ENO ( 

END I 

/♦ 

THE Entire, schedule is prinied out by the loop below. 

ALL resources AND THFIH SRECIFTC JOB ASSIGNMENTS ARE DISPLAYED, */ 
DO 1*1 TO NUM«£R (SRESOUftCe.F C6TYP6) ) I 
SNAME = label (l-RFSOUPCe.i* (STYPE) U) ) < 

WRITF SNARE* ’SHFSOURCE.*’ (STYPE) (I) .ASSIGNMENT I 
END t 

END PROjECT_SCHfc>,ULTNS * 


Fig, 4,3-5 PLANS Code for Time Transcendent Project 
Scheduling Algorithms 
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4.4 


FLIGHT ASSIGNMENT 


4.4.1 Problem Statement 

The problem to be solved is to find launch dates for a set 
of payloads, each of which has a launch window; i.e., an interval 
during which it must be launched if it is launched at all. Re- 
sources that are required to launch the payloads are specified 
by quantity and type. For example, each launch requires one 
orbiter, two solid rocket motors, three crewmen, etc. Since the 
resources may be reused after a flight, the scheduling must as- 
sign the cycling resources in a way that permits as many payloads 
to be launched as possible. 

4.4.2 Problem Model 

All resources for the problem can be modeled as item-specific 
resources. That is, each specific orbiter, crewman, launch pad, 
etc should be given a separate identity so that each can be 
tracked through the launch and turnaround processes separately. 

It is sufficient in this example to define a single process, 
FLIGHT, with the appropriate required resources as illustrated 
below: 

$PR0CESS 

FLIGHT 

REQUIRED__RESOURCES 

PAYLOAD 

i 

i 

INTERVAL 

START - 0 
END - 21 
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ORSHER 

(t 


i 

INTERVAL 

START - 0 
END - 21 
SRM 

i 

i 

INTERVAL 

START - 0 
END - 14 
DESCRIPTORS 

INITIAL 

QUANTITY - 2 

Each of the resource types appearing in $PR0CESS should ap- 
pear in the $RES0URCE tree with the specific resources under each 
type. In addition, the payloads and their windows should appear 
in $RE$0URCE. At input, $RES0URCE would have the structure: 

$RES0URCE 

ORBITER 

0RBITER_02 
0RBITER_05 
ORBITER 06 


SRM. 

SRM J 190 
SRM_A06 


PAYLOAD 

PAYL0AD_07 

WINDOW 

START - 217 
END - 238 
PAYLOADJ09 
WINDOW 

START - 240 
END - 271 
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4.4.3 Program Logic 


In the program, illustrated in Figure 4.4-1, the module 
NEXTSET performs the function of finding the next time after a 
given input time that a complete set of required resources of 
the correct types and quantities will be available. It examines 
the assignments in $RES0URCE to find this time. In addition, the 
module returns the identifiers of the specific resources that 
correspond to this time. Thus, NEXTSET provides the fundamental 
logic needed to build a time-progressive scheduling heuristic. 

(See Volume III, Section 2.4.12 for a complete functional descrip- 
tion of the NEXTSET module). 


PROCEDURE (iRESOURCEt SPROCESS) I 
ORDER SRESOURcEf PAYLOAD BY -ELEMENT •MINOOW. START* 

-ELEMENT, WINDOW. END I 

IFLIOHT a SPROCESS* PL IOhT I 
sfli6HT,jo0_interval. start a 0 I 

GRAFT SFLI0HT. DURATION AT SFLIQHT. J08.lNTERVAL.EN0 I 
aUILD.SCHEOULE_DNlTt 

/• 

THE HOOUlE ’NEXTSET' MAKES ALL OF THE RESOURCE ASSIGNMENTS FOR THE 
NEXT FlIGHT'ANO CREATES A TREE (SNEXTSET) WHICH IS READY TO 0C 
PLACED IN SSCHEOULE. HERE IT IS ASSUMED THAT THE PAYLOAD WITH THE 
NEAREST WINOnW OPENING TIME WILL BE USED. «/ 

CALL NEXTSET <<FLlGHT*SfiESOURCE . payload III, WINDOW, START* 

SRESOURCE.PAYLOADll) .WINDOW. END* SRESOURCEfSNEXTSET.SWINOOWS) I 
IF snextseT identical To SNUlL then go To output I 
START.TIMC ■ INEXTSET.JOB.INTERVAL. START » 

✓* 

THE CODE BELOW DETERMINES IF A DIFFERENT PAYLOAO SHOULD BE SUBSTI- 
TUTED ON this FLIGHT DUE To ITS NEARER WINDOW CLOSING TIME. •/ 
SCAnOIOATeS ■ SrESOURCE, payload, ALLMELEMENT, WINDOW, START <■ 

START.TIME L ELEMENT. WINDOW. END >• START.TXmEI I 
IF ACANDlDATEs IDENTICAL To SnULL 

THEN SKEEP • LABEL (SRESOURCE.PAVLOAD 1 1 1) I 
ELSE DO » N » INFINITY I 
FIND_MINIM0M_END.TIHE« 

GRAFT SCANDIDATES.FIRSTj IELEMENT.WINOO a.ENU < N) AT *T£mP i 

IF stemp not Identical to snull 

THEN 00 I N a STEMP, WINDOW. END I SKEEP > LABEL (STEMP) t 
GO TO FINP.MINIMUM.EN0.TIME I 

END < 

END t 

/• 

since the payload has been chosen, the next flight can BE SCHEDULED 
after updating the 'ASSIGNMENT* INFORMATION IN SRESOURCE, */ 
LABEUSNEXTSET, RESOURCES. PAYLOAOC In - LABEL (SKEEP) I 
GRAFT SRESOURCE. PAYLOAO. WLASEL (SKEEP) AT $SCHEOULEO..JAYLOADS (NEXT) I 
GRAFT SnEXTsEt AT SJ08 U I t 
CALL UPDATE.KE$OURCE(SJOB*SRESO(JRCE) I 
GRAFT SjOB(l) AT SSCHEOULE (NEXT) I 
GO TO 8UILD.SCHE0ULE.UNIT I 
OUTPUTS write SSCHEOULE « 

/• 

SINCE THIS Program modifies thf structure of sresoorce. the loop 

BELOW IS NEEnEO To RESTORE IT TO ITS ORIGINAL FORM, •/ 

DO iBi TO NUMBER(tSCMEDULEU_PAYLOAOS) I 

GRAFT INSERT SSCHEDULED_PAYlOADS ( 1) AT SRESOURCE, PAYLOAD (I ) | 

END I 
STOP I 

END FLIQHT.ASSIGnMEnT t 

Fig, 4.4-1 Example of FLAUS Code for FLIGHT 
ASSIGNMENT Algorithm 




4 * 
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After the next flight time and set of resources are deter- 
mined by NEXTSET, a choice of payloads may exist for that flight. 
The logic illustrated finds all the payloads whose windows con- 
tain the next flight time and then chooses the one whose window 
closes the soonest after the flight time. 

Finally, the logic updates $RES0URCE by calling the module 
UPDATE_RESOURCE and adds a new flight to the schedule being 
stored in $SCHEDULE. The detailed specifications for UPDATE_ 
RESOURCE are found in Volume III, Section 2.4.16* 

4.4.4 Changes to Problem Scope 

The code illustrated applies to any combination of resources 
in any quantitites properly defined in $PR0CE$S and $RES0URCE. 
For example, new cycling resources could be added; that is, 
vertical assembly building, flight control centers, etc could 
be added to the flight resources without changing the code. 
Furthermore, the process called FLIGHT need not require all of 
its resources for the same time intervals; the diagram below 
illustrates a resource set that is accommodated merely by chang- 
ing the $PR0CESS data without changing the illustrated code. 

ORBITER (1) 

CREWMEN (4) 

RECOVERY SHIP (2) 

SRMS (2) 

LAUNCH PAD (1) 

REFURBISHMENT 
FACILITY (1) 

TIME 
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Another illustration of a change in the problem scope that 


could be accommodated without a coding change concerns the model- 
ing of resources that undergo descriptor changes as a result of 
being assigned. Suppose that the process FLIGHT were defined to 
require crewmen with no previous flight experience. $PR0CESS 
might look like: 

$PR0CESS 

FLIGHT 

REQUIRED_RESOURCES 

CREWMAN 

DESCRIPTORS 

(t 

INITIAL 

EXPERIENCE - NONE 
FINAL 

EXPERIENCE - VET 

The appearance of the intial descriptor, EXPERIENCE, with a 
value NONE would cause the module NEXTSET to look only for crew- 
men with no experience. After being assigned to a flight, a crew- 
man would have a value VET for EXPERIENCE as a result of the 
action of the module UPDATE_RESOURCE and thus, would not be chosen 
again. Thus, without changing the code, we have introduced non- 
recycling resources into the system. In the terminology of the 
operations model, this has been accomplished by generalizing 
item-specific resources, with implicit descriptors only, to item- 
specific resources with explicit descriptors . Note that explicit 
descriptors have the distinguishing property of being changed 
by a process and retaining their new value after the process has 
terminated . 
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